Re: allocation of key material into keys
"C. Harald Koch" <chk@border.com> Mon, 28 October 1996 21:30 UTC
Received: from relay.hq.tis.com by neptune.TIS.COM id aa28651; 28 Oct 96 16:30 EST
Received: by relay.hq.tis.com; id QAA14008; Mon, 28 Oct 1996 16:34:54 -0500
Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma014006; Mon, 28 Oct 96 16:34:27 -0500
Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id QAA08541 for <ipsec@tis.com>; Mon, 28 Oct 1996 16:36:19 -0500 (EST)
Received: by relay.hq.tis.com; id QAA14002; Mon, 28 Oct 1996 16:34:24 -0500
Received: from mail.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma014000; Mon, 28 Oct 96 16:34:15 -0500
Received: by janus.border.com id <18437-1>; Mon, 28 Oct 1996 16:34:21 -0500
Message-Id: <96Oct28.163421est.18437-1@janus.border.com>
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>
cc: Ran Atkinson <rja@cisco.com>, ipsec@TIS.COM
Subject: Re: allocation of key material into keys
References: <199610282029.PAA03172@thunk.orchard.medford.ma.us>
In-reply-to: sommerfeld's message of "Mon, 28 Oct 1996 15:29:06 -0500". <199610282029.PAA03172@thunk.orchard.medford.ma.us>
From: "C. Harald Koch" <chk@border.com>
Organization: Secure Computing Canada Ltd.
Phone: +1 416 368 7157
X-uri: <URL:http://www.eng.border.com/homes/chk/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2; hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm; z:NJ7pss)l__Cw+.>xUJ) did@Pr9
Date: Mon, 28 Oct 1996 16:36:06 -0500
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
In message <199610282029.PAA03172@thunk.orchard.medford.ma.us>, Bill Sommerfeld writes: > Here's a rephrase which I think is more precise. Let me know if this > is not what you intended.. > > I'd like to propose that the key management protocol > specifications only be responsible for generating a "blob" of > key material at least N bits long containing at least K bits of > entropy. For obvious reasons, K <= N. > > Each transform would need to specify minimum values for K and > N, and precisely how to transform a variable-length "blob" > of key material of at least N bits into the session keys, initial > sequence numbers, and other shared state it needs. The problem with this is that it doesn't cover the problem of creating *independent* keys for multiple transforms, which is the concern Hugo raised. I suspect that everyone will define simple keying material functions such that one could (for example) derive the HMAC-MD5 key from a cracked DES key. As has been discussed, this is a key management layer issue. I'd modify your statement to include that somehow, the "blobs" handed to different transforms or algorithms must be 'independent' (i.e. it's cryptographically hard to derive one key from another). They can still be generated from the same key exchange, as long as the key manager runs an intermediate step to obscure the source keying material. -- C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd. chk@border.com | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7157 (voice) | "Madness takes its toll. Please have exact change." +1 416 368 7789 (fax) | -Karen Murphy <karenm@descartes.com>
- allocation of key material into keys Ran Atkinson
- Re: allocation of key material into keys Bill Sommerfeld
- Re: allocation of key material into keys C. Harald Koch
- Re: allocation of key material into keys Bill Sommerfeld
- Re: allocation of key material into keys Naganand Doraswamy
- Re: allocation of key material into keys David Carrel