Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis

["Paterson, Kenny" <[e-mail]>]

Hi

On 13/01/2015 16:39, "Manuel Pégourié-Gonnard" <[e-mail]> wrote:
>On 06/01/2015 11:35, Paterson, Kenny wrote:
>> It's good that nothing supports the truncated-MAC extension, because, in
>> combination with TLS's support for variable length padding, it
>>introduces
>> a security vulnerability. See:
>> 
>> http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf
>> 
>> 
>> which shows that if the tag size (MAC length) is shorter than the
>>CBC-mode
>> block size, then there's a distinguishing attack that can tell the
>> difference between the encryption of a short message and a longer
>>message
>> (even though both are padded to the same size before encryption).
>> 
>But if one does not expect any length hiding, is there still a problem
>with
>truncated MACs?

I think one would expect length hiding at least up to the granularity of
the block size in TLS with CBC mode. (The RFC even suggests that more
should be possible: "Lengths longer than necessary might be desirable to
frustrate attacks on a protocol that are based on analysis of the lengths
of exchanged messages." [1])

As a special case of the general attack, consider a notional application
using TLS that sends either the message "YES" or the message "NO". Suppose
we negotiate truncated MACs, and the TLS Record Protocol implementation
selects the amount of padding to add at random (from the set of possible
padding lengths allowed under the TLS padding scheme).

By truncating the ciphertext, doing some bit flipping, and reinjecting the
modified ciphertext, an adversary can tell whether "YES" or "NO" was
originally encrypted. (This assumes that the minimum amount of padding is
NOT selected; this happens with probability roughly 15/16 under the above
assumptions.) 

I'd consider that to be an attack in your "don't expect any length hiding"
setting - after all, the difference in plaintext lengths is just 1 byte,
which is well below the CBC-mode block size. Does that seem reasonable, or
is it still outside your attack model?

Cheers

Kenny

[1] RFC 5246, Section 6.2.3.2