CODEWITHSUNDEEP
phpopensslaesmcrypt
JM4
JM4

Reputation: 6788

Is openSSL encryption enough?

I have sensitive information stored in a database which goes through the following process:

  1. user enters information through webform.
  2. information entered is encrypted using AES 256-bit and salted using unique id to each user (although this is stored in the same database, and sometimes same table).
  3. The encrypted pass 1 data is THEN parse through openssl_pub_encrypt function
  4. data is stored in mysql database with fieldtype: varbinary

to decrypt the data:

  1. the private key is stored OFF the server and must be uploaded in a temporary file EVERY time the data needs to be retrieved
  2. the code runs through openssl_private_decrypt
  3. the code is run through a decrypt with the same salt and AES-256 script.

What I am wondering is running the information through the AES-256 bit in this instance even worth it (since key is offline, and the salt is already stored within the table if the data ever became compromised)?

Upvotes: 0

Views: 619

Answers (2)

caf
caf

Reputation: 239061

There is no point encrypting the data with a key that is available in the same place as the encrypted data.

However, it would be an advantage if you used a separate public/private key pair for each user - that way, if a private key leaks, you are only exposing one of your records instead of all of them.

By the way, openssl_public_encrypt() / openssl_private_decrypt() is not really the right function to use - it's a lower-level function intended for encrypting randomly generated keys, not to directly operate on the data. The right, higher-level functions are openssl_seal() / openssl_open().

Upvotes: 1

Marc B
Marc B

Reputation: 360702

Salting makes no sense on symetrically encrypted data, which is what you've got with AES-256. If anything, it'd just make any potential cracker's job easier by putting some known plaintext within the data. After all, ANY key will "decrypt" the data, but only one key will produce the original data. By putting a chunk of known plaintext in there, you've made it far easier to determine if the key being used is valid or not ("is salt text there, if so key is valid").

If the data's so sensitive that you have to take these precautions, I'd be more worried about the exposure window when the key file is actually stored on the server, as well as the traces it will leave behind in memory and on-disk, even after you've removed the file.

Upvotes: 3

Related Questions