Encrypting the entire database

I am working on a php / mysql application and want to keep the entire information in the database in the encrypted form.

The encryption / decryption functions and the encryption key will be used from a dll file and i will get the dll file registered on the server.

Can anyone suggest - what kind of encryption functions i should use and what kind of key i should have.

I want the strongest encryption possible by maintaining an acceptable speed of the application.

The application is expected to have around 50 concurrent connnections at the peak hours.

May find this interesting: http://www.phpbuilder.com/board/showthread.php?t=10326721

this is generating the same ciper each time.

My requriement is different ciper text each time even if the encrypting value and the key is same each time.

You should never, never, never use a home-brewed encryption algorithm.

You especially shouldn’t use this one (as it makes no attempt to evenly distribute character frequency, the plaintext could be guessed rather trivially).

Your original question doesn’t give enough information. Are you thinking of encrypting all the information in your database, or the database file as it rests on your server? The latter is useless (because you’ll have to decrypt it every time you start your PHP script), while the former is useful with a limited application. Sensitive information should be encrypted if possible, but there’s generally no need to encrypt everything – remember that the purpose of a web page is to actually process and display data, so data which isn’t extremely private shouldn’t be encrypted, solely because it’s going to be trivially retrievable anyway.

As for your final point about speed: with will formed encryption algorithms, speed is the anathema of security. The faster an algorithm operates, the less resistant it is to brute-force attacks. In this case, it’s fast or secure: pick one.

How do you plan to decrypt the data, then?

Well i want to encrypt the informaiton itself that is being stored in the database.

the thing is i will be using a shared hosting and hence want to encrypt it in that way - that if the db file is accessed by anyone - the data itself is useless to them and plus my php application will not have the encryptiona nd decryption functions and keys and those will be stored in a dll file and hence the entire app will be secure.

any suggestion on it.

using a decryption algorithm.


You cant encrypt something multiple times with the same data and key and get different results - if you do, then you wont be able to decode it without guessing.
Simple Shift: 1 up, 1 down:

If I gave you the encrypted text is CBU… what was my original text? BAT, or DCV?

Don’t use shared hosting.

Encryption on shared hosting will not make it any harder.

Encrypting the database content just means you can’t make use of the actual features of using a database. You may as well just dump the whole lot into a flat file.

In any case since the code to do the decryption will be on the server anyone with access to the database will have access to decrypt it as well.

This thread is starting to sound like this thread.

Felgall - i will be storing the encryption , decryption function and the key in a dll file.

you still think it is not safe.

Plus my php code will be zend guarded.

What do you advise?

Well you could burn it to a CD and then wipe it from your site, then smash the cd and bury the pieces in the garden.:lol::lol:

Encrypting the database defeats the entire purpose in using a database in the first place since you will have to retrieve and decrypt everything before being able to process any of it.

Anyway if you have a DLL on the site to do the decryption then anyone can use that to access a decrypted copy of the data.

Anyone who gets access to the server to be able to even see if the database is encrypted or not has already got access to far more than just the data anyway. At that point they can do whatever they like with your site whether the data is encrypted or not. You’d do better to spend the time tightening security to keep them out of the server.

The PHP encoders are not a bullet proof solution. Storing the keys in a DLL file won’t do anything because someone can just request the DLL file to decrypt the data (your PHP file can decrypt; why can’t something else?), not to mention that someone can decompile the DLL.

To properly do this, you need to buy physically secure servers and then separate your web-facing server from your internal server.

While this is true, it’s not what would be considered best practice for securing web servers. Ideally, if you’re dealing with highly sensitive information, you should be using an N-Tier architecture (where N is a minimum of 3). Your architecture should look something like this:

Heavily Hardened Web Server
Encrypted Pipe
Intermediary Decryption Server
Encrypted Pipe
Database server with Encrypted Data

The web server should sit in your network’s DMZ, and as noted be fully hardened from all known attacks. Firewalls should protect the connection between that an the intermediary server (which should only accept well-formed, authenticated connections from the web server). Additionally, the Database server should only accept well-formed, authenticated connections from your intermediary server. All of these servers should be in physically secure (and ideally, physically remote) locations.

In this design, encrypting the database does not provide a large amount of additional security, but it helps to prevent attacks by malicious or ignorant insiders (which comprise a significant portion of attacks against sensitive information), but it also doesn’t cost much in terms of overall implementation (as you should still use a 3+ Tier architecture if you’re not encrypting), so it’s usually worthwhile from a defense in depth position.

The key is to know the type of information you’re going to be storing. This level of security is expensive, so it’s really only generally worthwhile if the risk or potential impact of a breach is high. Usually, this means things like storing Credit Card info, Social Security Numbers or HIPAA protected information.

Well I assume that the OP is on a tight budget and the information is not so terribly important, otherwise he wouldn’t be considering shared hosting.

there you go with the hyperbole again, stephen

the “entire” purpose?

in a word: no

I agree as well, but I’m of the opinion that forum threads like this can live something of a “long-tail” life, where their impact may not be immediately obvious to the participants. As such, when I start seeing things like “encrypting the database defeats the entire purpose” I feel like it’s probably a good idea to provide a bit of best practice to the thread, in case someone comes looking for it months or years from now.

Just a personal preference.

Okay then what do you gain from using a completely encrypted database that you do not get just by using an equivalent flat file structure or a collection of files containing keyed records?

With the data encrypted your ability to optimise queries is lost.
With the data encrypted your ability to define relationships is lost.