GCM Implementation and TLSCompressed.Length
alfredo.pironti at inria.fr
Tue Oct 18 13:30:28 CEST 2011
Thank you very much, that clarified things a lot. I re-read docs in
this perspective and things work now (still, I find TLS RFC a bit
misleading when citing padding in the AEAD section).
Practically, when I have an AEAD ciphertext in GCM mode, I subtract 16
to its length (in bytes), and that's the plaintext length, isn't it?
On Tue, Oct 18, 2011 at 12:01 AM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> 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 22.214.171.124, the additional data (AD) for AEAD
>> consist of "seq_num + TLSCompressed.type + TLSCompressed.version +
>> 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.
>> 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.
> Help-gnutls mailing list
> Help-gnutls at gnu.org
More information about the Gnutls-help