4

This is going back a ways... Schneier discusses SKIPJACK at Declassifying Skipjack. Schneier offers a link to a reference implementation at ftp://ftp.funet.fi/pub/crypt/cryptography/symmetric/skipjack (it is still alive). The unoptimized reference implementation is written by Panu Rissanen.

NIST provides the SKIPJACK test vectors in SP800-17, Table 6, pp. 140-42. NIST withdrew the the encryption specification, but left the decryption information and test vectors for interoping with legacy systems.

What I find is the reference implementation and NIST implementation differ. Rissanen's code does not arrive at a NIST Known Answer for the KAT's offered by NIST.

I'm trying to understand why Rissanen's code is not conforming to the NIST KATs. My question is, what is the history of SKIPJACK back then? Did the algorithm have several variants?

1 Answers1

2

TL;DR - Rissanen's code, based on the released spec, is big-endian; everything else is little-endian.

I hunted down what seemed to be going on here and Rissanen's unoptimized reference implementation gives exactly what you expect based on the May 1998 "Skipjack and KEA Algorithm Specifications" document. The example key (0x00998877665544332211) and plaintext (0x33221100ddccbbaa) are hard-coded into that program, and give the exact results as listed on page 18. So these values are 'big-endian': 0x00 is the MSB in key, and 0x11 the LSB; likewise, 0x33 is the MSB in the plaintext, and 0xaa the LSB.

Every other implementation seems to process everything as little-endian: all of the key, plaintext, and ciphertext (not surprising as it shares the same buffer as the plaintext, transformed in-place). The test vectors in NIST SP800-17 tables 5 and 6 work directly as they appear for most of the these little-endian implementations, but to get the unoptimized reference implementation to match you have to switch endian-ness. It's really as easy as reversing the vectors of key and plaintext (no odd byteswapping craziness). Nothing in SP800-17 would make you believe that the Skipjack vectors are little-endian, whereas the DES vectors in tables 1 through 4 are big-endian, but that seems to be the case. Implementations which agree with SP800-17 seem to be the ones you're likely to actually come across, but if you try to make your own based on the "Skipjack and KEA Algorithm Specifications" document, you'll have to reverse everything to get interoperability.

If you change lines 45 & 46 (the plaintext and key) in the unoptimized reference implementation

  unsigned char in[8] = { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 };
  unsigned char key[10] = { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x80 };

You'll get

    w1  w2   w3  w4
   -----------------
 0 00000000 00000000
 1 4a374a36 00000000
 2 4f084f0a 4a360000
 3 93c993ca 4f0a4a36
 4 9f09d53b 93ca4f0a
 5 2bcf64c0 d53b93ca
 6 a7883444 64c0d53b
 7 249af1a6 344464c0
 8 78fd1c35 f1a63444
 9 34442382 64c1f1a6
10 f1a62011 17cc64c1
11 64c1c801 d1bc17cc
12 17cc37ed acccd1bc
13 d1bc3a6c 202caccc
14 accc3a40 ebde202c
15 202ce720 9683ebde
16 ebde8872 c71c9683
17 85c71355 8872c71c
18 a3df64d1 13558872
19 a0462827 64d11355
20 46b755f6 282764d1
21 47942350 55f62827
22 ade885d9 235055f6
23 674a32ab 85d92350
24 efbaccf2 32ab85d9
25 85d92a67 235132ab
26 32ab33dc afa42351
27 235198dc 016cafa4
28 afa4bdb6 bb91016c
29 016c5b6d 120fbb91
30 bb91bbf4 5a1f120f
31 120f86cb 007a5a1f
32 5a1f4641 94e4007a

Reverse the result and you'll find 0x7a00e49441461f5a, the correct result for the 0x80000000000000000000 key (note the location of the 0x80 byte).

geitda
  • 21
  • 2