Timeline for answer to Creating HMAC for PHP encryption by Phil
Current License: CC BY-SA 3.0
Post Revisions
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 30, 2015 at 12:21 | vote | accept | texelate | ||
| Jan 28, 2015 at 21:00 | comment | added | Phil | No problem. I have tried to incorporate everything we discussed here. Thanks | |
| Jan 28, 2015 at 20:56 | history | edited | Phil | CC BY-SA 3.0 |
Added results from comments discussion back in to my answer
|
| Jan 28, 2015 at 11:05 | comment | added | texelate | Thanks, Phil_1984_. Do you want to include that in your answer and I'll accept it? | |
| Jan 27, 2015 at 15:45 | comment | added | Phil | Yes. You only need to include the data which you want to authenticate within the HMAC contents. If you always use the same method of encryption and decryption then there is no need to authenticate this since it is assumed. If you are familar with salts and hashing, it might be a good idea to think of HMAC as just a salted hash of contents where the key is the salt. HMAC = hash(key + contents). You can never find out the key from the hmac, and you need the key to be the same and the contents to be the same to end up with the same result. | |
| Jan 27, 2015 at 7:32 | comment | added | texelate | I thought so re security. So really if a HMAC was done once on just encrypted data + IV that wouldn't lead to any issues so long as your other variables relating to hashing and encryption are constant? I'm storing IV, salt and encrypted data in separate DB fields so, although your link was interesting, I am not trying to keep them in an AES file. | |
| Jan 24, 2015 at 21:53 | comment | added | Phil | ALGORITHM just represents some algorithm and was used as an example to detail that issue. I was not referring to some magic file format which should be used for storing encrypted files. Please see my AES Crypt link if you are looking for a file format. | |
| Jan 24, 2015 at 20:54 | comment | added | Phil | How you use your encryption/decryption layer is what is important here. Generally, assumptions are bad in software. If your application code makes the assumption that the decryption was successful and acts on the erroneous data, it could be harmless or it could be very bad. Whether it is a "security risk" depends on your definition, but it certainly would be classed as a problem which exists at the encryption/decryption layer. But no, it is not a security risk which makes it easier to crack the underlying encryption if that's what you're asking. | |
| Jan 24, 2015 at 14:58 | comment | added | texelate | Also, is there a case to HMAC the other information such as the algorithm used to hash password (e.g. 'pbkdf2') or the password's salt? Or is HMACing ALGORITHM + IV + ENCRYPTED DATA enough? I don't want to HMAC data I don't need to. Finally, is the 'ALGORITHM' just an arbitrary text representation of of the mcrypt cipher mode used? E.g. could be 'MCRYPT_RIJNDAEL_128' | |
| Jan 24, 2015 at 14:48 | comment | added | texelate | "This is bad because you can end up with a corrupted encrypted file with a valid HMAC." This doesn't pose any security risk though, does it? | |
| Jan 24, 2015 at 11:35 | comment | added | Phil | Depending on the padding used, authentication by checking for valid padding is nearly always less reliable than using a hmac. It might randomly create a valid padding by accident even with a bad decryption. | |
| Jan 24, 2015 at 10:23 | comment | added | Artjom B. | It can still be check if the decryption was successful if the encryption library checks all bytes of the padding. If there is even one error in the padding, it can throw an exception or something like that. An HMAC prevents you from doing the decryption if it is corrupted. | |
| Jan 23, 2015 at 22:54 | history | answered | Phil | CC BY-SA 3.0 |