response to Last Call on: IP Authentication using Keyed MD5
hugo@watson.ibm.com Fri, 30 June 1995 20:00 UTC
Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12693 (5.65c/IDA-1.4.4 for <archive-ipsec@ftp.ans.net>); Fri, 30 Jun 1995 16:00:33 -0400
Received: by interlock.ans.net id AA56788 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 30 Jun 1995 15:49:05 -0400
Message-Id: <199506301949.AA56788@interlock.ans.net>
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 30 Jun 1995 15:49:05 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 30 Jun 1995 15:49:05 -0400
Date: Fri, 30 Jun 1995 15:10:28 -0400
From: hugo@watson.ibm.com
To: ho@cs.arizona.edu
Cc: ipsec@ans.net
Subject: response to Last Call on: IP Authentication using Keyed MD5
Ref: Your note of Tue, 27 Jun 1995 15:21:54 -0700 (attached) Hillary and all, The draft I posted was intended to have the minimal information needed for implementation of the keyed-MD5 primitive and not to explain the rationale of the choice of this particular mechanism. Explaining this rationale in a consistent and accurate way is not easy. It requires getting into the mathematical details of the analysis. However, I have sketched the ideas in notes to this list in the past. In a separate message I am sending another (more extensive) explanation of these ideas. As for the cited papers: The Preneel-VanOOrschot paper is now available. I've just learned that the RSA Cryptobytes publication is not yet in electronic form (I am told that it will be soon). As for my own paper with Bellare and Canetti [BCK], which is the strongest basis for the analysis I have, it is currently written in a "very mathematical" form, including detailed proofs of the main results. However, it lacks a good "human interface" which may be more useful for most people in this list (e.g., the practical meaning of these results, the difference in approach to previous work, etc.). This will still take a while until done (we are all busy with many other things). However, I may make the proofs available to you or other specifically interested people; let me know if you are interested. In the meantime, the high level description I am sending in the next message will hopefully help to clarify some of these issues. Hugo ----------------------------- Note follows ------------------------------ Date: Tue, 27 Jun 1995 15:21:54 -0700 From: Hilarie Orman <ho@cs.arizona.edu> To: hugo@watson.ibm.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199506270121.AA40361@interlock.ans.net> Subject: Re: response to Last Call on: IP Authentication using Keyed MD5 The draft repeats a defect that Van Oorschot noted with respect to draft-ietf-ipsec-ah-md5-03.txt, that it does not address the desired security properties of the transform. I realize that "better than brand X and costs no more" is meant to be a compelling argument, but some reference to absolute criteria would be useful. Why is the padding is changed from 128-bits to 512-bits in the initial key setup? Is this to allow pre-computation? If so, this should be noted so that it is not confused with a security consideration. I cannot find any of the references for the security of the method. I was only able to see a copy of the preprint of Crypto '95 paper for a few minutes and have received no replies to requests for a copy, the URL http://www.rsa.com/rsalabs/cryptobytes/ is non-existent, another reference is a "manuscript". It seems unreasonable to ask the group to make a decision if none of the background material is available to it.