[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: deriving keying material from the shared secret

Yes, this is a good idea. I don't know, however, if we should specify
a generic algorithm for all crypto algorithms; or each crypto
(e.g., DES, HAMC-MD5, etc.) should specify its own transformation
to transfer a n-bit keying material to a m-bit key ? Where n could be
either greater than, equal to, or less than m.

The advantage of per-algorithm transformation is that some algorithm
may have special considerations. For example, DES may require special
processing if the result of the transformation is a DES weak key
(as suggested bt teh isakmp-oakley draft).


Regards, Pau-Chen

> From ipsec-request@neptune.tis.com Mon Jul  1 10:49:46 1996
> Message-Id: <199606302320.TAA00201@smb.research.att.com>
> X-Authentication-Warning: smb.research.att.com: smb owned process doing -bs
> From: Steve Bellovin <smb@research.att.com>
> Mmdf-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
> To: ipsec@TIS.COM
> Subject: deriving keying material from the shared secret
> Date: Sun, 30 Jun 1996 19:18:51 -0400
> Sender: ipsec-approval@neptune.tis.com
> Precedence: bulk
> Content-Length: 2145
> Status: RO
> 
> The particular secrecy and authentication transforms we are considering
> need varying amounts of keying material.  For example, the current ESP
> draft (draft-ietf-ipsec-esp-des-md5-02.txt) uses two 56-bit DES keys
> (though it extracts 64-bit chunks), a single 64-bit IV (why one instead
> of two?), and a 128-bit HMAC key.  A mechanism for deriving these keys
> from the shared secret is given in the text; it involves a 512-bit
> pad field whose contents varies, and MD5.
> 
> By contrast, the current MD5-HMAC draft (draft-ietf-ipsec-ah-hmac-md5-00.txt)
> uses a variable-length key apparently taken directly from the shared
> secret, crunching it through MD5 if needed to reduce it to 64 bytes if
> needed.
> 
> I suggest that we have one standard method of extracting keys from
> the shared secret, probably spelled out in a separate RFC.  It is
> important, in my opinion, to make it extremely difficult to derive
> one key given one of the others derived from the same shared secret.
> For example, suppose one can determine the IV used for the ESP
> transform as defined; we don't want to make it easy to determine
> the session keys from the IV.
> 
> The derivation mechanism used in the ESP draft is probably wrong, since
> it uses MD5 run on the concatenation of a constant string (which differs
> for each key) and the shared secret.  Since the constant string is
> 64 bytes long, the natural input block length of MD5, when the secret
> is crunched in it is equivalent to running MD5' on just the secret,
> where MD5 differs from MD5 only in the starting values of the state
> registers A, B, C, D.  If the shared secret is, say, 155 bits (and I
> think that that will be common, if elliptic curves are used and if I'm
> reading the Oakley spec correctly), then the attacker need only go after
> one of the simpler cases for attacking MD5.  (A forthcoming draft paper
> will show why it may be relatively easier to get the key for one direction
> than for the other.  And given the key, the IV is trivial to recover.)
> 
> Possibly, we should run HMAC on the padding string, using the shared
> secret as the key.  At the least, I suggest that MD5(key,constantstring)
> would be more secure.
> 
> Comments?
Follow-Ups: