- From: <HUGO@watson.ibm.com>
- Date: Fri, 27 Dec 96 16:18:27 EST
- To: karlton@netscape.com, dpkemp@missi.ncsc.mil
- cc: ietf-tls@www10.w3.org
Ref: Your note of Tue, 17 Dec 1996 11:17:25 -0800 (attached) Philip L. Karlton writes: > > > 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. > > I have a pretty good imagination. :-) I am paid to have imagination... As explained in a previous message, this is not an issue of wild imagination. I advise against mixing of MD5 and SHA in HMAC based on the analytical results that we have on these functions, and everything we know about the comparative strength of SHA vs MD5. > > Another issue concerns the MAC for the Finished messages. There was MUCH > discussion about whether they should be constructed like HMAC rather > than the ad hoc algorithm that was chosen. The tradeoffs are fairly > simple. > > pro) Using HMAC is more secure (probably). > > con) The server has to retain the entire handshake until it > can compute the master_secret. The storage requirements > for heavily used secure servers could be prohibitive. > (Some information, e.g. the server's certificate chain > is probably constant across all handshakes; and that > helps a little.) I will not get into the discussion of whether retaining the entire handshake data until master_secret is computed is a real problem or not. If it is decided that it is not a real problem just go with HMAC on the full handshake data. If it is decided that it is a problem then it still does not justify going to ad-hoc constructions. Just define that you compute MAC(master_secret, HASH(handshake_messages+Sender)) where HASH is a plain (unkeyed) hash function , e.g. SHA. In this case you can still use the generic specification with MAC (and whatever realization of MAC you choose to use), and you also make clear that you authenticate HASH(handshake_messages+Sender) rather than the full handshake_messages. (Which means that you assume your HASH to be collsion-resistant). As for computing two MAC's, one based on SHA and one on MD5, you can still choose to do that. Though, it will be probelmatic to define using a single generic MAC notation. As Dan Simon said, if you do so you MUST use two different keys for each of the MAC algorithms. I personally believe that this is not worth the complexity though concatenating -- as opposed to mixing -- two MACs cannot be weaker than doing only one (at least if you use two independent keys to key the MACs). Hugo > > PK > -- > Philip L. Karlton karlton@netscape.com > Principal Curmudgeon http://www.netscape.com/people/karlton > Netscape Communications Corporation > > Everything should be made as simple as possible, but not simpler. > -- Albert Einstein >
Received on Friday, 27 December 1996 16:48:53 UTC