On 10/17/2011 05:59 PM, Alfredo Pironti wrote: Hello Alfredo,
I'm a post-doc researcher at INRIA, France, and I'm developing a TLS implementation (with the goal of formal verification), and I would like to include support for AEAD ciphers (e.g. AEAD_AES_128_GCM). However, I got stuck because of the following problem. According to RFC 5246, sec 6.2.3.3, the additional data (AD) for AEAD consist of "seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length". Computing such AD, and in particular TLSCompressed.length, is feasible when encrypting. However, when decrypting it seems impossible to me to retrieve that value (indeed it should be secret, and the AEAD ciphertext should not reveal the size of the plaintext, right?
The supported AEAD ciphers in TLS are stream thus the length of the ciphertext is the length of the plaintext. The spec prevents block AEAD ciphers or any kind of random padding to be added in the future.
After all, in the Mac-then-encrypt mode of TLS, random padding is added for this exact purpose -- and TLSCompressed.length becomes available only after decryption, and before mac verification). Can you please explain me where am I wrong?
You are not. The spec was published in haste. However it works because the currently supported AEAD ciphers are stream.
regards, Nikos _______________________________________________ Help-gnutls mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-gnutls
