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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 8, 2011 at 7:51 PM, Eric Rescorla <ekr@xxxxxxxx> 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?

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?

regards,
Nikos

[0]. http://www.ecrypt.eu.org/documents/D.SPA.13.pdf

[1]. For an HMAC the square root of
the internal state of the hash algorithm is also affecting the
security level.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]