How to hide encryption key?

my_name

How does one go about hiding an encryption key?

Let's say that a user sends info to my site, my script encrypts the info via a key, and the script stores the encrypted version into the database. Obviously, the key is within my PHP code. To decrypt the information later, I simply use the same key that's within my PHP code.

Then, someone -- somehow -- gets into my system, able to view my database files. Okay, so the person can only view the encrypted version. But couldn't this person simply grab my key out of my PHP code and decrypt it himself/herself?

Maybe I'm missing something. I can understand encrypting a stream, but is it really beneficial to encrypt stored information? If someone is good enough to get into my site to begin with, aren't they going to be smart enough to open up my PHP code in Notepad and search out the key?

Someone set me straight. 🙂 Thanks.

MarkR

No, there is absolutely no point in doing what you describe, for the reason you describe.

If you're going to use encryption on a server, use it at a layer which is at least useful.

Some useful kinds of encryption:

Encrypt data between the client and the server - stopping packet sniffing
Encrypt data on the hard disc (but below what the application can see) - require a key to be entered each boot time (this means that if power is lost, the system will not automatically reboot)
Use asymmetric encryption to encrypt something as you store it on the server, which does not have the other part of the key, hence cannot then decrypt it (even if it is subsequently compromised - although an attacker can still capture new data by modifying the code)

Mark

my_name

Mark, thanks for confirming my suspicions. I've viewed a lot of sites that have tutorials on encrypting information to a database, but the thing that always got me was the fact that the key almost always just sat there in the "open," within the PHP script.

I was thinking of adding a layer of security by encrypting everything to the database, but so far, only the hashes (for passwords) really and truly seem useful.

On the other hand, I have another idea, where the user can optionally add a password to a piece of data to encrypt it, with it being understood that the user would have to share that "password" (i.e., the encryption key) with the reicipent, hopefully by some means other than through my system (e.g., by phone or face-to-face). I could be wrong, but that at least seems worth the effort of implementation to me.

n_wattam

why not berry the key within the content your encryting? or base your key on the content you encrypt.

Weedpacket

n_wattam wrote:
why not berry the key within the content your encryting? or base your key on the content you encrypt.

Sounds like a Catch-22. To decrypt the data you need the key. To get the key you need to decrypt the data.

Besides; if they can get the key from the source code they can get anything else from the source code - including how to get the key from the encrypted data.

n_wattam

Weedpacket wrote:
Sounds like a Catch-22. To decrypt the data you need the key. To get the key you need to decrypt the data.

Besides; if they can get the key from the source code they can get anything else from the source code - including how to get the key from the encrypted data.

nah think outside the box. say your key is 2 chrs in length, what you can do is take you encyrpted data, split it in to 2 parts A and B then rebuild it with your key in...

A + KEY + B,

to get the key you could reverse it. or you could scatter your key. in to single units, this would also disrupt your encryted data on its own being broken unless the key is known and removed from the layout and then processed on its own.

EDIT.
to make it more random i would work on a formula which would count the num of total chrs in the which the encrypted data is, then work on this to split the key in single units and scatter them around in the encrypted data.

Hopefully if the content is different all the time, the keys would be in different locations all the time, vus only the key can be found if

1 your method of storing the key is known,
2 your forumla is known on how you scatter the key.

Remembering without the key the only other way to decrypt data is to break it on its own, but by scattering different content (key) within the encrypted data would stop this, unles again they knew what you was doing and removed these bits first. etc

laserlight

Hopefully if the content is different all the time, the keys would be in different locations all the time, vus only the key can be found if

1 your method of storing the key is known,
2 your forumla is known on how you scatter the key.

Of course, since the assumption is that the attacker knows (or can discover) the algorithms, the attacker will know both #1 and #2.

n_wattam

laserlight wrote:
Of course, since the assumption is that the attacker knows (or can discover) the algorithms, the attacker will know both #1 and #2.

if the assumption is that the attacker does know or can discover the algorithms, then needing the key is erelivent IMHO, as you could soon break an encryption knowing how its encrypted based on how long your key is and simulating all the combinations of keys.

laserlight

if the assumption is that the attacker does know or can discover the algorithms, then needing the key is erelivent IMHO, as you could soon break an encryption knowing how its encrypted based on how long your key is and simulating all the combinations of keys.

For a strong cryptosystem, the key space is large enough that a brute force attempt by trying all possible keys is impractical. The attacker doesnt know how long the secret key is, nor should the attacker even know a single bit (literally) of the secret key.

You really need to read up on cryptography. Try some of the sites listed at the Cryptography directory on dmoz.

n_wattam

laserlight wrote:
Of course, since the assumption is that the attacker knows (or can discover) the algorithms

Based on the above quote, the attacker would then know the following info, would he not? 😃

laserlight wrote:
The attacker doesnt know how long the secret key is, nor should the attacker even know a single bit (literally) of the secret key.

laserlight wrote:
trying all possible keys is impractical

Now that would all depend on what the information is, and how bad its wanted 😃

laserlight

Based on the above quote, the attacker would then know the folling info, would he not?

I dont know what you mean by "folling" (it isnt a word, as far as I know). My guess is that you are confusing the secret key with the cryptosystem.

Now that would all depend on what the information is, and how bad its wanted

Hence one must choose an appropriate cryptosystem, and a key that is sufficiently large for one's needs.

EDIT:
n_wattam, I'm pretty sure my_name knows all this, so we are going off topic here. Feel free to contact me via the MSN IM network if you want to continue our discussion.

MarkR

If an attacker gains access to your machine, they can take copies of the entire application and all its data to work on cracking it offline.

In cryptography, you should always assume that the algorithm is known to an attacker.

If the key is not contained anywhere within the data he has, you should assume that the cipher is strong enough that the attacker cannot use brute force to attack the key (if not, use a longer key with more bits).

It is difficult to brute force a decent cipher with a keysize of 128 bits or more.

However, if the key is ANYWHERE within the application, you should assume that an attacker will find it. As they have access to all of your code (not necessarily source code, but still enough), they will be able to determine how it decrypts it. Or even, not bother, simply run it and let your own code do the decryption.

This is why such approaches are basically useless.

Mark