3

I'm working on a php script and are using mcrypt to encrypt/decrypt arbitrary data.

When I decrypt encrypted data, using another key (e.g. I typed in the wrong password), the output won't be correctly decrypted of course.

If the wrong key has been used I would like to display an error message, but I'm thinking it's quite hard to validate the output string as correct "plaintext" (since the chars in the encoded data are also valid as input data).

Is there any way to get around this?

As I was writing this question, I got an idea :)

Could I possibly prefix the input data with a static "control" string and use this for validation when I decrypt?

José
  • 391
  • 3
  • 14
  • Have you thought about using a hash to verify the key before decryption? – Gumbo Sep 03 '11 at 10:51
  • Edit: I don't have any checksum for the key saved (in a database etc), so this can't be done in my case right? – José Sep 03 '11 at 11:08
  • Basically, you store a hash of the original key besides the encrypted data. Then before decrypting the encrypted data with a given key, you calculate the hash of the given key with the same hashing algorithm and compare the result with the stored hash. If the hashes are identical, the keys are also (most probably) identical. (See also [integrity verification using cryptographic hash functions](http://en.wikipedia.org/wiki/Cryptographic_hash_function#Verifying_the_integrity_of_files_or_messages)) – Gumbo Sep 03 '11 at 11:12
  • 2
    I do not recommend storing the a hash of the key besides the encrypted data. It's a lot easier for an attacker to figure out the password using bruteforce if she can just try them against the hash instead of decrypting the entire file. – Emil Vikström Sep 03 '11 at 11:24

2 Answers2

1

I usually do this:

  • Hash the input data (file or message or whatever).
  • Encrypt the data.
  • Prepend the encrypted data with the IV and the hash of the data.
  • Send or store the IV + hash + ciphertext.

As the IV and hash are always the same length, there is no need to add padding or control characters.

On the receiving or reading side:

  • Extract the IV.
  • Extract the hash.
  • Extract and decrypt the encrypted text.
  • Hash the decrypted data and check if it does match the extracted hash.

So, you store the hash of the source data, NOT the hash of the key. As a commenter posted above, giving away the hash of your key is a vulnerability, as the attacker now needs only to search it in a rainbow table (it would compromise your data in a matter of seconds).

You idea of storing a control string is good too (certainly is faster) but it cannot allow you to confirm the message or data is indeed uncorrupted, only that the correct key was used.

MV.
  • 947
  • 1
  • 11
  • 14
  • 2
    Another way is to prepend hash to the raw data BEFORE to encode it. here is what I use: https://gist.github.com/3965357 – Meglio Oct 27 '12 at 17:20
  • Yes, that's another way. As long as the "control reference" string can only be recovered or matched (or both) with the correct encryption key, it will work. Even using your linked code, which uses really only a small part of the hash. (However, I wonder why you used only four bytes from the hash; the shorter the hash, higher the chances of collision. Space/size constraints in you application maybe?) – MV. Oct 28 '12 at 06:15
  • Even with 4 bytes collision probability is 1/14^4 - more then enough for 1million records database. After all, data must be just consistent. If it is - then it is correct otherwise it would not decrypt at all. Eg in my scenario I use it for valudation if decryption was successful or not. If it was - then I assume it isconsustent. P.s. another example about collosion would be clickbank receipt number. They have 8 chars only and it is enough for all the history of all their sales. Regards, Anton. – Meglio Oct 29 '12 at 08:47
0

The best way to add integrity to you encrypted data is to add MAC created ONLY on encrypted data.

Don't apply MAC on plain text, because MAC can reveal some information about that text. MAC is not created to provide security - only integrity.

So, right algorithm would be ENCRYPT-THEN-MAC!

More detailed information is available in this video http://d396qusza40orc.cloudfront.net/crypto/recoded_videos%2F7.4%20%5B974a4c90%5D%20.mp4

Eugene Fidelin
  • 2,049
  • 23
  • 22