Re: [TLS] About TLS 1.2 AEAD ciphers definition

[Joshua Davies <[e-mail]>]

On 05/27/2010 11:42 AM, Juho Vähä-Herttua wrote:
> On 27.5.2010, at 19.04, Adam Langley wrote:
>    
>> On Thu, May 27, 2010 at 11:29 AM, Juho Vähä-Herttua<[e-mail]>  wrote:
>>      
>>> So I'm curious to know how is AEAD actually handled and how to find out the
>>> TLSCompressed.length when constructing additional_data for AEAD-Decrypt? I'm
>>> sure there are more experienced people here who can tell me the answer.
>>> Thank you in advance.
>>>        
>> I believe that none of the currently defined AEAD ciphers introduce
>> padding, so it's pretty easy for the moment.
>>      
> The only currently defined AEAD ciphers seem to be AES_128_GCM and AES_256_GCM defined by RFC 5288. I'm a bit surprised that AES encryption doesn't introduce padding though, it might be just me misunderstanding the GCM process but I thought it still needs to pad the input data to match the block size, doesn't it? The TLSv1 explicit padding of CBC ciphers is not present in the AEAD ciphers at all. RFC 5288 doesn't define any kind of padding either, which makes me wonder how it is actually implemented...
>    
Aren't all AEAD ciphers derivatives of "COUNTER" mode?  My understanding 
of "COUNTER" mode was that it flipped the initialization vector around 
(encrypted the IV rather than the input block) so that no padding was 
ever necessary.

	



<http://twiki.dev.sabre.com/twiki/bin/view/Travelocity/TVLYArchitecture>