From: Matt Blaze <mab@crypto.com>
To: N/A
Message Hash: 8822451e991cecc41610b95022ca0706a316125661055dbdfd1f925c6a4a876c
Message ID: <199508121738.NAA05367@crypto.com>
Reply To: <199508112206.SAA27354@crypto.com>
UTC Datetime: 1995-08-12 17:30:21 UTC
Raw Date: Sat, 12 Aug 95 10:30:21 PDT
From: Matt Blaze <mab@crypto.com>
Date: Sat, 12 Aug 95 10:30:21 PDT
Subject: Re: Still more "S-1" foolishness
In-Reply-To: <199508112206.SAA27354@crypto.com>
Message-ID: <199508121738.NAA05367@crypto.com>
MIME-Version: 1.0
Content-Type: text/plain
I wrote:
>Here's a table of where the expanded key schedule bits come from
>(I think - this could be wrong, I had to tweek some of the output
>by hand). Note that some key bytes are used much more often, and
>in more positions, than others, but every key byte does at least
>end up being used as input to each F eventually (but not always to
>each "target" byte).
>
>Sorry for the opaque notation; this reads best when used in conjunction
>with Colin's cool graph that he posted to sci.crypt last night.
>
Whoops - there was a bug in my understanding of what was going on
that conspired with a bug in my table generation program to make everything
wrong. Here's the correct table, for those interested. Sorry for the noise.
-matt
R | | G0 G1 F+0 F+1 F+2 F+3 (this key byte is input to this fn)
O bytes| R+4 R+5 R+2 R+3 R+0 R+1 (key byte is mixed with this block byte)
U |enc-| all all R+6L R+6H R+7L R+7H (output affects this byte)
N |rypt| 0 1 2 3 4 5 (key schedule byte #)
D |ed |LLHH LLHH LLHH LLHH LLHH LLHH (posn of orig key byte in sched byte)
======================================
0 76 5831 9425 5362 4738 8492 5038
1 10 1497 5081 1928 0394 4058 1694
2 32 7053 1647 7584 6950 0614 7250
3 54 3619 7203 3140 2516 6270 3816
4 76 9275 3869 9706 8172 2836 9472
5 10 5831 9425 5362 4738 8492 5038
6 32 1497 5081 1928 0394 4058 1694
7 54 7053 1647 7584 6950 0614 7250
8 76 3619 7203 3140 2516 6270 3816
9 10 9275 3869 9706 8172 2836 9472
10 32 5831 9425 5362 4738 8492 5038 (number indicates position in schedule
11 54 1497 5081 1928 0394 4058 1694 of original key bytes; an entry
12 76 7053 1647 7584 6950 0614 7250 "5678" means key bytes 5 and 6 are
13 10 3619 7203 3140 2516 6270 3816 in the low order position of this
14 32 9275 3869 9706 8172 2836 9472 schedule entry and bytes 7 and 8
15 54 5831 9425 5362 4738 8492 5038 are in the high order position. Bytes
16 76 1497 5081 1928 0394 4058 1694 are first run through an F functuon
17 10 7053 1647 7584 6950 0614 7250 and XORd with each other to create
18 32 3619 7203 3140 2516 6270 3816 the schedule nibble.)
19 54 9275 3869 9706 8172 2836 9472
20 76 5831 9425 5362 4738 8492 5038
21 10 1497 5081 1928 0394 4058 1694
22 32 7053 1647 7584 6950 0614 7250
23 54 3619 7203 3140 2516 6270 3816
24 76 9275 3869 9706 8172 2836 9472
25 10 5831 9425 5362 4738 8492 5038
26 32 1497 5081 1928 0394 4058 1694
27 54 7053 1647 7584 6950 0614 7250
28 76 3619 7203 3140 2516 6270 3816
29 10 9275 3869 9706 8172 2836 9472
30 32 5831 9425 5362 4738 8492 5038
31 54 1497 5081 1928 0394 4058 1694
Return to August 1995
Return to “Matt Blaze <mab@crypto.com>”
1995-08-11 (Fri, 11 Aug 95 14:58:24 PDT) - Still more “S-1” foolishness - Matt Blaze <mab@crypto.com>