Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx

[Eric Rescorla <[e-mail]>]

On Wed, Mar 9, 2011 at 4:06 AM, Martin Rex <[e-mail]> wrote:
> Hovav Shacham wrote:
>>
>> Martin Rex <[e-mail]> wrote:
>> >
>> > it looks that the recommendation of rfc-2104 section 5 about truncation
>> > should apply here as well.
>>
>> What RFC 2104 is saying is that the security of a k-bit truncation of HMAC
>> when using an underlying n-bit hash is min{k,n/2}.  Setting k to a value
>> less than n/2 means that you k-bit security; setting k to a value equal to
>> or larger than n/2 means you have (n/2)-bit security.
>>
>> Any truncation of HMAC-SHA384 -- the PRF at hand -- to fewer than 384/2
>> = 192 bits means you are in the former regime rather than the latter.
>>  That's fine, provided k-bit security is sufficient, as 96-bit security is
>> here; it just means that having built HMAC using SHA384 was overkill, which
>> it of course was.
>
> What I'm reading here is that a truncation of an HMAC or an HMAC-like
> construct to 96 bits cuts the effective security down to 96-bit.
>
> You call the use of SHA-384 for the HMAC in such a situation "overkill",
> I call it cryptographic imbalance.
>
> A sensibly balanced truncation would truncate to _no_ less than half
> the output size of the underlying hash function, which means at
> least 192 bits in accordance with with the recommendation in
> rfc-2104 (HMAC) section 5.
>
> Is that correct?

As Hovav says, what's imbalanced isn't the truncation, it's the use of SHA-384.

As I said to Nikos, it's useful to remember how we got here, which is
not that the
TLS WG suddenly developed a desire to modernize the hash functions at the core
of TLS. The combination of MD5 and SHA-1 would quite likely have been
fine indefiintely
except that Wang started breaking both MD5 and SHA-1. This left us in
the situation
where we needed new, non-broken hash functions. However, the only such
functions *also* had a longer output size. Sometimes this is useful,
sometimes it's
annoying.

As a simpler example, let's consider the case of the message MAC,
currently untruncated
HMAC-SHA-1 with an output size of 160 bits (20 bytes). The security
level of this
MAC against forgery/tampering is 160 bits under brute force attack. Now consider
a world where HMAC-SHA-1 is really broken [not the current world] and we need
to transition to HMAC-SHA-256. The "balance" argument you're proposing would
have us use accept an extra 12 bytes of MAC output size even though the previous
security level was fine. However, as Hovav suggests, the situation is
that we just
don't have another 160-bit hash function at hand to replace SHA-1, so
instead we're
forced into using one that's really too big. In other words, overkill.

-Ekr