3 ms·
Suppose you have a server with its own encryption key, and a key-value database full of encrypted data (secured by this root keyset) associated with a user. Ev
by hxtk 1y ago
Suppose you have a server with its own encryption key, and a key-value database full of encrypted data (secured by this root keyset) associated with a user.
Even if I gain access to the database, if the keys are managed securely, I can't read another user's data (or even really my own). I have to go through the authorization logic of the application that will decrypt it on my behalf.
However, if I can create a row in the database with my ID and another user's data, I can then convince the server I am authorized to view that cell, and it will happily decrypt it on my behalf, assuming something like AES-CTR or some other stream cipher without authentication.
Authenticated encryption like AES-CTR-HMAC solves that problem, because now the application will see that I am authorized to view that cell (because it sees the user ID matches mine) and it will decrypt it for me (using that user ID as the associated data), but the decryption will fail because the associated data does not match, leaving me unable to exfiltrate the data that I convinced the server belonged to me, and probably setting off some kind of alarm because that sort of decryption should never fail unless things have been tampered with.
I'm not overly fond of the example and I find it confusing as well. I think the example may be a bit confusing because the term "authentication" is overloaded between application-level authentication and cryptographic authentication, i.e., "if the chat protocol authenticates the user ID" sounds like it is talking about the user logging into the server securely. The user is authenticated by having a secret negotiated with the server. In the next bullet, they talk about "authenticating" the associated data, referring to it in the cryptographic context, but they don't indicate why that would be a problem because in their example, the malicious actor still doesn't have the key. The article handwaves it as "the attacker might be creative."
If they had the key, but not the associated data, you'd still be in a relatively bad situation, because the associated data is not secret. It doesn't serve as a second key because it is not high enough entropy and is ideally zero entropy conditional on already having all information from the originating context.
- vlovich123 1y agoBut why bother putting the user id in the AD instead of part of the authenticated encrypted payload?
- hxtk 1y agoIt sounds like you are assuming that if the data were modified, decryption would fail catastrophically and you'd end up with garbage. This is precisely the point of AEAD: providing cryptographic guarantee that decryption will fail catastrophically if things are tampered with. That guarantee is not provided with unauthenticated stream ciphers. For example, some stream ciphers work by essentially using a deterministic but unpredictable PRNG seeded with the key and IV to generate a bitstream, and then XOR the plaintext with that bitstream to generate the ciphertext. With such a stream cipher, If Eve knows that the data format is, e.g., the an 8-byte unsigned integer user ID followed by the rest of the payload, Eve can take the first 8 bytes of the ciphertext and XOR it with Bob's user ID (public information) and her own user ID to corrupt the message in such a way that the ID in the resulting cleartext would contain her user ID instead of Bob's, and thus pass the validation that it seems like you are proposing. Let C[] be the cipher text, K[] be the key stream, B be Bob's ID, and E be Eve's ID: C[:8] = B ^ K[:8] C[:8] ^ B = K[:8] C' = C[:8] ^ B ^ E ++ C[8:] C' would decrypt, validate as "belonging" to Eve, and contain Bob's data.
- vlovich123 1y agoNowhere did I say I used an unauthenticated cipher. It was all authenticated cipher. Indeed, usually it was still AEAD (AES-GCM), but instead of using the offset as the AD I simply derived a new key from the offset, thus not using the AD part. This way I would swap out the algorithm to an authenticated cipher that wasn't AEAD (e.g. AES-CBC+HMAC) without breaking how anything worked.
- hxtk 1y agoIt sounds like the source of confusion is in terminology. I would consider AES-CBC+HMAC to be an AEAD construction, and I would consider whatever "secret key" you pass into HMAC along with the ciphertext to be the "associated data". AES-GCM is an AEAD construction that gives you the MAC organically as part of the cipher, but that is not what makes it AEAD as I understand it. If you are using an AEAD cipher mode, then you always have AD, but sometimes that AD might be the empty string. In that case, the advantage to using contextual AD as opposed to using the empty string as AD and then doing additional verification on the decrypted object is that it prevents some kinds of timing attacks, because cryptographic libraries will often implement AEAD constructions to fail in constant time, where as your scheme will take longer if post-decryption validation of contextual data encoded in the plaintext fails compared to if decryption fails.