Additional suggested cleanups for TLS

Ref:  Your note of Tue, 17 Dec 1996 12:47:50 -0500 (attached)

David P. Kemp writes:

 > I agree completely, and support the PRF proposals from Dan and Hugo.
 > Hugo also mentioned some other topics:
 >  1) The form of the PRF used by IPSEC, which uses an appended one-up
 >     counter to generate successive key blocks, is not optimal.

I addressed this issue in my previous note

 >  2) Mixing MD5 and SHA in a single ad-hoc function probably doesn't
 >     buy anything because it is difficult to imagine a situation in
 >     which SHA is broken but MD5 remains sound.
 > This sounds reasonable, and I'd support using a "better PRF" based
 > on non-mixed HMAC-SHA.

This is more than just imagination, it is the result of our analysis
of HMAC.

If one uses HMAC with SHA and MD5 mixed, say,
MD5(K XOR opad + SHA(K XOR ipad + data))
then if SHA is broken as a "weak collision resistant function" (see our
Crypto'96 paper) OR if the compression function of MD5 (keyed through its
IV) is broken as a pseudorandom function, then no analytical security is
left to back the construction.  In this sense this mixed construction
gives you the security of the weaker among the two functions.
Thus, use SHA for both iterations!

Note: This is to be contrasted with the use of both SHA and MD5 to hash data
before applying digital signatures.
Something like SIG(SHA(data)+MD5(data)) CANNOT be weaker than just
But the above case with PRF is different!

 >  3) For integrity purposes (not for signatures!) it may be more secure
 >     to truncate the SHA output to 128 bits.
 > Although the suggestion originally had nothing to do with security (it
 > was motivated by the desire to have the same size output for MD5 and
 > SHA), the idea that truncating keyed hash functions may improve their
 > robustness by hiding some state is intuitively appealing.  But I don't
 > know if there is enough of a theoretical basis yet to suggest using
 > HMAC-SHA-128.

There is no definitive theoretical answer here.
If you read Preneel-van OOrschott (Crypto'95) you'll
see some concrete advantages of truncation in the case
of specific attacks.
Actually, truncation of MAC functions (eg based on DES)
is an old practice.
Still this is not an absolute proof that truncation must help
in the case of HMAC.
Given all the evidence and well-educated guesses,
I RECOMMEND for the case of HMAC-SHA1 going from 160 bits to 128 bits.
(This is defined in the upcoming RFC on HMAC as HMAC-SHA1-128)

NOTE: do not confuse this case with truncation of unkeyed hash functions
where truncation weakens the function significantly against birthday
attacks. The case of MAC is different. Actually [PV] show that in some
sense truncation of MAC helps against birthday attack (sounds confusing
but is true).



Received on Friday, 27 December 1996 16:31:58 UTC