Re: deriving keying material from the shared secret
Uri Blumenthal <uri@watson.ibm.com> Mon, 01 July 1996 17:28 UTC
Received: from relay.tis.com by neptune.TIS.COM id aa25716; 1 Jul 96 13:28 EDT
Received: by relay.tis.com; id NAA10999; Mon, 1 Jul 1996 13:30:59 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma010994; Mon, 1 Jul 96 13:30:33 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05329; Mon, 1 Jul 96 13:30:34 EDT
Received: by relay.tis.com; id NAA10986; Mon, 1 Jul 1996 13:30:29 -0400
Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma010978; Mon, 1 Jul 96 13:30:08 -0400
Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id NAA13677 for <ipsec@TIS.COM>; Mon, 1 Jul 1996 13:33:13 -0400
Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/5/18/96) id AA22958; Mon, 1 Jul 1996 13:32:47 -0400
From: Uri Blumenthal <uri@watson.ibm.com>
Message-Id: <9607011732.AA22958@hawpub.watson.ibm.com>
Subject: Re: deriving keying material from the shared secret
To: pau@watson.ibm.com
Date: Mon, 01 Jul 1996 13:32:47 -0400
Cc: ipsec@TIS.COM
In-Reply-To: <9607011545.AA21226@secpwr.watson.ibm.com> from "pau@watson.ibm.com" at Jul 1, 96 11:45:26 am
Reply-To: uri@watson.ibm.com
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
pau@watson.ibm.com says: > 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. I would prefer for each transform to have its own algorithm for deriving keys from keying material. [Of course, it would be nice, especially for those mildly paranoid like me (:-) to ensure that there is reliable "one-way valve" between the keying material and the derived keys, so that a weaker transform did not compromise stronger keys.] -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- <Disclaimer>
- deriving keying material from the shared secret Steve Bellovin
- Re: deriving keying material from the shared secr… pau
- Re: deriving keying material from the shared secr… Hilarie Orman
- Re: deriving keying material from the shared secr… Uri Blumenthal
- Re: deriving keying material from the shared secr… Bill Sommerfeld
- Re: deriving keying material from the shared secr… Phil Karn
- Re: deriving keying material from the shared secr… Uri Blumenthal