I have encrypted AES key stored in the database with the encrypted data. AES key is encrypted with a key derived from the passphrase. I want to ensure the integrity of the stored AES key. Is the checksum (SHA-256) of the plain key all I need or is there something more to it?
Asked
Active
Viewed 111 times
1
-
1What are you worried about? 1) accidental data corruption, 2) intentional tampering, 3) the key being incorrectly decrypted due to use of the wrong passphrase, or 4) something else? – Joseph Sible-Reinstate Monica Oct 20 '18 at 14:24
-
Mostly incorrect passphrase, also data corruption and tampering – Tuomas Toivonen Oct 20 '18 at 16:01
1 Answers
1
Since you say you're worried about intentional tampering, that immediately limits your solutions to digital signatures, message authentication codes, or authenticated encryption. Your setup doesn't seem to have or need any asymmetric keys, so that rules out digital signatures.
- Message authentication codes: derive two keys from the passphrase instead of one. Use the first key to do the encryption and decryption, and the second key to MAC the ciphertext. If the MAC fails, you know that either the passphrase is wrong or the data has been modified.
- Authenticated encryption: Galois-Counter Mode (GCM) is a popular choice for authenticated encryption. Using it as your AES mode of operation will fulfill all of your requirements.
![](../../users/profiles/127145.webp)
Joseph Sible-Reinstate Monica
- 7,110
- 3
- 21
- 35
-
Why wouldn't the SHA-256 hash of the *plain text* key be secure? So the encrypted key is first decrypted using the passphrase (derived key), and then the hash is compared – Tuomas Toivonen Oct 20 '18 at 17:20
-
1Because of [the doom principle](https://moxie.org/blog/the-cryptographic-doom-principle/), among many other reasons. – Joseph Sible-Reinstate Monica Oct 20 '18 at 17:28
-
I don't see how the doom principle (padding attack) counts here. Isn't it based on the oracle, which freely responds to attacker's queries to decrypt the ciphertext? And the MAC verification before decryption would prevent the attacker to exploit the oracle. But for the data at rest, I don't see connection... What is the exact case where attacker would figure out or tamper the key, by having read/write access to the ciphertext key and the SHA-256 of the plain text key? What is oracle here, as the decryption key is derived from user-entered password in the first place, and not stored anywhere? – Tuomas Toivonen Oct 21 '18 at 06:18