Re: [TLS] Issue 66: HMAC-256 based ciphersuites

["Bodo Moeller" <bmoeller at acm.org>]

On Jan 10, 2008 11:37 AM, MIURA, Fumiaki <miura.fumiaki at lab.ntt.co.jp> wrote:
> At Wed, 09 Jan 2008 10:30:17 +0100, Florian Weimer wrote:
> > * Fumiaki MIURA:
> > > At Tue, 8 Jan 2008 12:53:25 +0200, <Pasi.Eronen at nokia.com> wrote:

> > >> TLS_RSA_WITH_AES_256_CBC_SHA256

> > > Why not SHA512 for AES256?
> > >
> > > For example, FIPS 180-2 say that `security (bits)' for SHA-512 is 256
> > > in page 3.

> > Does this estimate also apply when using SHA-512 as a building block
> > for an HMAC?

> I think yes, theoretically.

Theoretically, this is true.  (By the way, note that there are now two
generations of research papers with HMAC security results:

http://www-cse.ucsd.edu/users/mihir/papers/hmac.html
http://www-cse.ucsd.edu/users/mihir/papers/hmac-new.html

The latter says that collision attacks against a hash function don't
mean it is bad for HMAC.  Still it's probably a very good idea to
phase out SHA-1.)

However, if we look specifically at TLS, we have a sequence number
space of size 2^64, which is quite far away from the 2^128 where we'd
expect to run into birthday collisions with SHA-256.  So the
theoretical attack doesn't apply, and we should be able to expect more
than 128 bits of security from HMAC-SHA-256 as used in TLS.  In fact,
even 128-bit MAC security should be perfectly fine even for
applications requiring 256-bit encryption security.  This is because
the reason for demanding such a huge security margin is long-term
security -- we are thinking of attackers who might spent half an
eternity trying to break our encryption.  The window for potential
attacks against MAC authentication in TLS, in contrast, is closed once
the connection is over.

Bodo


_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls