4 ms·

According to RFC 5116 [1], there is 'associated data' (AD) as well as an authentication tag (similar to a MAC). It seems like both can be used to verify the aut

According to RFC 5116 [1], there is 'associated data' (AD) as well as an authentication tag (similar to a MAC). It seems like both can be used to verify the authenticity of the ciphertext, but the article only mentions the AD part. When do you use which? The JDK8 documentation for the Cipher class has a paragraph on AEAD. This mentions AAD; unencrypted "Additional Associated Data", but also calls the same thing "Additional Authentication Data". Pretty confusing. [1] http://www.ietf.org/rfc/rfc5116.txt http://www.ietf.org/rfc/rfc5116.txt [2] http://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html http://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher...

agl 11y ago
Any authentication tag is a detail of the AEAD. As a practical matter, in order to provide authentication, the AEAD must expand the plaintext and, in some AEADs, that expansion comes in the form of a tag. But some AEADs just pad the plaintext with zeros and use a variable-block cipher (i.e. AEZ), in which case there's no tag as such. Either way, it's an internal detail of the AEAD that someone using it doesn't need to know about. The AEAD just needs to signal an error at decryption time if the ciphertext has been manipulated. The associated data(⁺) is just an input that needs to be equal at encryption and decryption time. It can be empty, or it could be a counter, but it could also be some other form of context, e.g. a string “payload for attachment #3 of message #234982374”. It's there to make sure that ciphertexts are understood in the correct context, but it's not included in the ciphertext itself. The Java docs (and Java's crypto APIs are terrible in general I'm afraid) call the AD both “associated data” and “additional authentication data”. That's just a mistake. At the very least they should be consistent within themselves and I think they should pick “associated data” as the term to use. (⁺) I called it “additional” data in my post, but since the RFC calls it “associated” I changed it to that. It's the same thing.

agl 11y ago

Any authentication tag is a detail of the AEAD. As a practical matter, in order to provide authentication, the AEAD must expand the plaintext and, in some AEADs, that expansion comes in the form of a tag. But some AEADs just pad the plaintext with zeros and use a variable-block cipher (i.e. AEZ), in which case there's no tag as such. Either way, it's an internal detail of the AEAD that someone using it doesn't need to know about. The AEAD just needs to signal an error at decryption time if the ciphertext has been manipulated. The associated data(⁺) is just an input that needs to be equal at encryption and decryption time. It can be empty, or it could be a counter, but it could also be some other form of context, e.g. a string “payload for attachment #3 of message #234982374”. It's there to make sure that ciphertexts are understood in the correct context, but it's not included in the ciphertext itself. The Java docs (and Java's crypto APIs are terrible in general I'm afraid) call the AD both “associated data” and “additional authentication data”. That's just a mistake. At the very least they should be consistent within themselves and I think they should pick “associated data” as the term to use. (⁺) I called it “additional” data in my post, but since the RFC calls it “associated” I changed it to that. It's the same thing.