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

In general - since pseudorandom-ness of the output was NOT a design principle or criteria of hash functions (until SHA3) - truncating hash output is problematic from crypto point because you cannot reasonably assume that all the output bits have the "entropy" spread over them equally.

--
Regards,
Uri

----- Original Message -----
From: Martin Rex [mailto:mrex@sap.com]
Sent: Tuesday, March 08, 2011 02:23 PM
To: Eric Rescorla <ekr@rtfm.com>
Cc: tls@ietf.org <tls@ietf.org>; ietf@ietf.org <ietf@ietf.org>
Subject: Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx

Eric Rescorla wrote:
> 
> >
> > I'm sorry, but I think it is a bad idea to use a flawed design for
> > the TLS finished message by subverting the collision resistence
> > of stronger secure hash functions that are used for the PRF.
> 
> Yes, I realize you think that, but until you offer a cryptographic
> argument for that opinion I guess we're just going to have to disagree.

You got it backwards.  I say that it is a bad idea to truncate
a PRF based on SHA-256 to 96, and even worse idea to truncate a
PRF based on SHA-384  -- and anyone who wants to do that should
better provide a good cryptograhic argument.

Truncating HMACs and PRFs may have become first popular in
the IETF within IPSEC.

Looking at this table:

     http://tools.ietf.org/html/rfc4868#section-2.6

   +------------------+--------+--------+--------+--------+------------+
   |    Algorithm     | Block  | Output | Trunc. |  Key   | Algorithm  |
   |       ID         |  Size  | Length | Length | Length |   Type     |
   +==================+========+========+========+========+============+
   | HMAC-SHA-256-128 |   512  |   256  |  128   |  256   | auth/integ |
   +------------------+--------+--------+--------+--------+------------+
   | HMAC-SHA-384-192 |  1024  |   384  |  192   |  384   | auth/integ |
   +------------------+--------+--------+--------+--------+------------+
   | HMAC-SHA-512-256 |  1024  |   512  |  256   |  512   | auth/integ |
   +------------------+--------+--------+--------+--------+------------+
   | PRF-HMAC-SHA-256 |   512  |   256  | (none) |  var   |     PRF    |
   +------------------+--------+--------+--------+--------+------------+
   | PRF-HMAC-SHA-384 |  1024  |   384  | (none) |  var   |     PRF    |
   +------------------+--------+--------+--------+--------+------------+
   | PRF-HMAC-SHA-512 |  1024  |   512  | (none) |  var   |     PRF    |
   +------------------+--------+--------+--------+--------+------------+

If there existed a cryptographic argument (which you insist on) then
I'm sure there would be an HMAC-SHA-394-96 in the above list.

What is your argument why there should be a HMAC-SHA-384-96 in that list?
(which would apply to a ciphersuite with a SHA-384 based PRF and
finished messages truncated to 12 octets).

-Martin
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls