Slicing and dicing

Rodney Thayer <rodney@sabletech.com> Mon, 08 September 1997 21:09 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA21261 for ipsec-outgoing; Mon, 8 Sep 1997 17:09:38 -0400 (EDT)
Message-Id: <3.0.3.32.19970908171145.00773740@pop3.pn.com>
X-PGP-Key: <http://www1.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 08 Sep 1997 17:11:45 -0400
To: ipsec@tis.com
From: Rodney Thayer <rodney@sabletech.com>
Subject: Slicing and dicing
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
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>
>To: ipsec@tis.com
>Subject: Slicing and dicing
>Reply-To: Karl Fox <karl@Ascend.COM>
>Organization: Ascend Communications
>Sender: owner-ipsec@ex.tis.com
>
>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
>
>
>