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