[2840] in cryptography@c2.net mail archive
Preliminary analysis of F table for SKIPJACK
daemon@ATHENA.MIT.EDU (Frank (Giff) Gifford)
Wed Jun 24 18:59:33 1998
Date: Wed, 24 Jun 1998 18:44:30 -0400 (EDT)
From: "Frank (Giff) Gifford" <giff@eng.us.uu.net>
Reply-To: "Frank (Giff) Gifford" <giff@eng.us.uu.net>
To: cryptography@c2.net
Unlike the criteria used for DES, the F table in SKIPJACK doesn't have the
same properties for the avalance effect. In particular, a single input
bit change to a DES S-Box will change at least two bits in the output.
Not so in SKIPJACK.
Here are specific examples (Numbers in [] are the F values, so F(6) = 246)
In1: 6 [246], In2: 7 [244], InDelta: 1, OutDelta: 2
In1: 38 [ 96], In2: 39 [104], InDelta: 1, OutDelta: 8
In1: 58 [229], In2: 59 [245], InDelta: 1, OutDelta: 16
In1: 88 [ 90], In2: 89 [ 88], InDelta: 1, OutDelta: 2
In1: 156 [ 93], In2: 157 [ 92], InDelta: 1, OutDelta: 1
The only criteria I could see is that for any input change, the output
must change (i.e. F(a) != F(b) for a != b). But that's becuase each
element in F is used from 00..FF exactly once.
Here's a more complete table:
In 0 1 2 3 4 5 6 7 8
----------------------------------------------------------------
1: 0, 78, 208, 428, 592, 462, 188, 76, 16
2: 0, 198, 754, 1598, 1998, 1592, 770, 224, 34
3: 0, 486, 1542, 3046, 3974, 3196, 1582, 472, 38
4: 0, 528, 2048, 3938, 4864, 3906, 2036, 512, 88
5: 0, 460, 1536, 3228, 3928, 3132, 1530, 468, 54
6: 0, 228, 812, 1556, 2004, 1542, 784, 222, 20
7: 0, 64, 242, 478, 506, 438, 248, 68, 4
8: 0, 6, 26, 64, 54, 68, 30, 6, 2
Sum 0 2048 7168 14336 17920 14336 7168 2048 256
The first entry is numer of bits which have changed on the input. The
remaining numbers are how many outputs change by the given number of bits.
This is for all possible input deltas. Notice that no number remains the
same, but there are 2048 instances of only a single bit output change.
A skeptical person would say, "Hey! This is Version 2.0, dated 29 May
1998. I bet they gave out the right algorithm, but a different F table
than what was implemented in the Clipper chip." To disprove this, does
anyone want to try hooking up a Clipper chip to the newly released code
and check it out?
Personally I would want a 'stronger' table than what's there now.
My thanks to Paul Rissansn <bande@lut.fi> for typing in the skipjack.c
code and saving me the trouble of typing in the F box.
-Giff
