GCM Implementation and TLSCompressed.Length

[Nikos Mavrogiannopoulos]

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