Slicing and dicing

Karl Fox <karl@Ascend.COM> Mon, 08 September 1997 21:49 UTC

Received: (from majordom@localhost) by (8.8.2/8.8.2) id RAA21519 for ipsec-outgoing; Mon, 8 Sep 1997 17:49:09 -0400 (EDT)
Date: Mon, 08 Sep 1997 14:57:36 -0700
Message-Id: <>
From: Karl Fox <karl@Ascend.COM>
To: Rodney Thayer <>
Subject: Slicing and dicing
In-Reply-To: <>
References: <>
Reply-To: Karl Fox <karl@Ascend.COM>
Organization: Ascend Communications
Precedence: bulk

Rodney Thayer writes:
> A weak key test for 3des was listed in the 3des explicit-iv draft.

Thanks for the pointer.  Actually, it says

3.1 Weak Keys

   DES has 64 known weak keys, including so-called semi-weak keys and
   possibly-weak keys [Schneier95, pp 280-282].  The likelihood of
   picking one at random is negligible.

   For DES-EDE3, there is no known need to reject weak or
   complementation keys.  Any weakness is obviated by the other keys.

   However, if the first two independent 64-bit keys are equal (k1 ==
   k2), then the 3DES operation is simply the same as DES.
   Implementers MUST reject keys that exhibit this property.

I assume that the second paragraph then *proscribes* weak key tests
for automated key material derivation.  So I see there's no need to
test for weak keys in 3DES, but am now concerned that although we
compare for k1==k2, why is it we don't test for k2==k3?  And although
we do these tests on the SKEYID_d keymat, we don't for SKEYID_e.  Why
not?  Is my memory going bad, or didn't we agree that ISAKMP
encryption and authentication transforms would match AH/ESP
transforms?  If so, wouldn't this also then apply to the derivation of
keying material?

> It is my understanding that if bytes 1..8 yield a weak key that you toss
> that 'slice' and go on, so it would use bytes 9..16.

Thank you, that's what I was hoping for.  I'd like to suggest that the
document be changed to say so.
Karl Fox, servant of God, employee of Ascend Communications
655 Metro Place South, Suite 370, Dublin, Ohio  43017   +1 614 760 4041