Re: deriving keying material from the shared secret
Bill Sommerfeld <sommerfeld@apollo.hp.com> Mon, 01 July 1996 17:59 UTC
Received: from relay.tis.com by neptune.TIS.COM id aa26318; 1 Jul 96 13:59 EDT
Received: by relay.tis.com; id OAA11818; Mon, 1 Jul 1996 14:01:30 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011811; Mon, 1 Jul 96 14:01:02 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07365; Mon, 1 Jul 96 14:01:03 EDT
Received: by relay.tis.com; id OAA11804; Mon, 1 Jul 1996 14:01:00 -0400
Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1.1) id xma011801; Mon, 1 Jul 96 14:00:39 -0400
Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA096324191; Mon, 1 Jul 1996 11:03:11 -0700
Message-Id: <199607011803.AA096324191@relay.hp.com>
Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA198584190; Mon, 1 Jul 1996 14:03:10 -0400
To: Steve Bellovin <smb@research.att.com>
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Cc: ipsec@TIS.COM
Subject: Re: deriving keying material from the shared secret
In-Reply-To: smb's message of Sun, 30 Jun 1996 19:18:51 -0400. <199606302320.TAA00201@smb.research.att.com>
Date: Mon, 01 Jul 1996 14:03:09 -0400
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
All transforms which provide authentication and encryption need to resist a known-plaintext key-recovery attack. Using the strongest cryptographic part of the transform itself with the shared secret as the *key* and some known plaintext as input might be a good way to generate one or more keys for use by a given transform. If you need multiple keys, use multiple different known plaintexts. In the event the transform can't deal with a variable-length key, do some not-necessarily-cryptographic transform of the shared secret to come up with the fixed-length key (like the kerberos string-to-key bitwise-fanfold-and-xor approach). Upside: the resulting key generation should be no weaker than the transform itself is, assuming the shared secret is big enough. For instance, for 3DES, you wouldn't weaken a 168-bit 3DES key to 160 or 128 bits by funnelling the key material through SHA or MD5. Downside: you probably don't want to do this for algorithms where key recovery might become practical (e.g., single-DES) because you'll leak bits out of the shared secret that way. - Bill
- 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