On Wed, Mar 9, 2011 at 1:10 AM, Nikos Mavrogiannopoulos <n...@gnutls.org> wrote:
> On Tue, Mar 8, 2011 at 7:51 PM, Eric Rescorla <e...@rtfm.com> wrote:
>>>> Perhaps, but this isn't a digest but rather a MAC, and so the attack
>>>> model is different.
>>> You seem to be forgetting that the finished messages have been reused
>>> for other purposes already:
>> No, I'm not forgetting that. That doesn't change the fact that the
>> computation is
>> a MAC.
>
> I'm not a specialist in MAC algorithms but by checking
> the ECRYPT II[0] report of 2009-2010, I can try making some points.
> A MAC has a security level that depends on the size of the MAC
> and the size of the key. That is a 12-byte MAC has security level of
> MIN(2^{key_size}, 2^{96}) [1], irrespective of the key size used.
>
> As I understand the addition of SHA-384 as PRF was to increase
> the security margin of TLS comparing to the SHA-1 PRF. This
> is not occuring now because a MAC based on algorithm that
> returns 384-bits and truncates it to 96 can offer nothing more
> than an algorithm that outputs 160 bits and are trucated to 96.
> Hence there is no significant difference than SHA-1 or SHA-384
> in that case, so why define SHA-384 anyway?
If you recall, the reason why TLS 1.2 was done was not primarily because
of concerns about SHA-1's 160-bit output being large enough but because
people started developing analytic attacks on MD5 and SHA-1 that brought
it's security level down below the nominal level.
In other words, there are many applications where 80 bits of security is
fine, but people don't want to use SHA-1 because they don't trust it.
> For me the ciphersuites defined in TLS should have a uniform
> security level. I.E. why use AES-256 with security level of 2^256
> but use a MAC for a handshake of 2^96 bits?
Because the attack model for MACs is not the same as the attack model
for encryption. The encryption is susceptible to offline attack, whereas
with a MAC all you need to do is get the guessing probability sufficiently
low because *any* failed forgery causes connection termination.
-Ekr
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
