Slicing and dicing

Rodney Thayer <> Mon, 08 September 1997 21:09 UTC

Received: (from majordom@localhost) by (8.8.2/8.8.2) id RAA21261 for ipsec-outgoing; Mon, 8 Sep 1997 17:09:38 -0400 (EDT)
Message-Id: <>
X-PGP-Key: <>
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 08 Sep 1997 17:11:45 -0400
From: Rodney Thayer <>
Subject: Slicing and dicing
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

A weak key test for 3des was listed in the 3des explicit-iv draft.

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.

>Date: Mon, 8 Sep 1997 14:04:31 -0700
>From: Karl Fox <karl@Ascend.COM>
>Subject: Slicing and dicing
>Reply-To: Karl Fox <karl@Ascend.COM>
>Organization: Ascend Communications
>Appendix B of draft -04 of the resolution document says
>   The key for DES-CBC is derived from the first eight (8) non-weak and
>   non-semi-weak (see Appendix A) bytes of SKEYID_e.
>If the bytes 1-8 are a weak or semi-weak key, do we then go on to
>bytes 2-9 (I hope not!) or bytes 9-16?
>The same appendix later says
>   The key for 3DES-CBC is the first twenty-four (24) bytes of a key
>   derived in the aforementioned pseudo-random function feedback method.
>   3DES-CBC is an encrypt-decrypt-encrypt operation using the first,
>   middle, and last eight (8) bytes of the entire 3DES-CBC key.
>This means that no weak key test may be done for 3DES-CBC.  Was this
>the intent?
>Karl Fox, servant of God, employee of Ascend Communications
>655 Metro Place South, Suite 370, Dublin, Ohio  43017   +1 614 760 4041