Re: allocation of key material into keys
Lewis McCarthy <lmccarth@cs.umass.edu> Mon, 28 October 1996 23:25 UTC
Received: from cnri by ietf.org id aa27207; 28 Oct 96 18:25 EST
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa22407; 28 Oct 96 18:25 EST
Received: from neptune.tis.com by neptune.TIS.COM id aa06833; 28 Oct 96 17:48 EST
Received: from relay.hq.tis.com by neptune.TIS.COM id aa06688; 28 Oct 96 17:38 EST
Received: by relay.hq.tis.com; id RAA16334; Mon, 28 Oct 1996 17:42:25 -0500
Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma016330; Mon, 28 Oct 96 17:41:57 -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 RAA12532 for <ipsec@tis.com>; Mon, 28 Oct 1996 17:43:49 -0500 (EST)
Received: by relay.hq.tis.com; id RAA16326; Mon, 28 Oct 1996 17:41:55 -0500
Received: from freya.cs.umass.edu(128.119.40.195) by relay.tis.com via smap (V3.1.1) id xma016321; Mon, 28 Oct 96 17:41:46 -0500
Received: from thor.cs.umass.edu (thor.cs.umass.edu [128.119.41.73]) by freya.cs.umass.edu (8.7.6/8.6.9) with SMTP id RAA08608 for <ipsec@tis.com>; Mon, 28 Oct 1996 17:43:48 -0500
Message-ID: <32753724.3F54@cs.umass.edu>
Date: Mon, 28 Oct 1996 17:43:48 -0500
From: Lewis McCarthy <lmccarth@cs.umass.edu>
Organization: Theoretical Computer Science Group, UMass-Amherst
X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.0 alpha)
MIME-Version: 1.0
To: ipsec@tis.com
Subject: Re: allocation of key material into keys
References: <199610282029.PAA03172@thunk.orchard.medford.ma.us>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
[Mail from the ipsec list seems to arrive here substantially reordered, so please ignore this if it's already been covered.] 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. [...] At the risk of stating the obvious, the K bits of entropy should presumably be ~ evenly distributed among the N bits of VPIblob, i.e. padding K bits from a physical random source with 0s to reach N bits would be unacceptable. Otherwise a transform might grab a hunk of padding and use it as key material.... -Lewis <mailto:lmccarth@cs.umass.edu>
- Re: allocation of key material into keys Lewis McCarthy