Download Skipjack and Key Exchange Algorithm KEA | ECE 646 and more Study Guides, Projects, Research Cryptography and System Security in PDF only on Docsity!
SKIPJACK and Key Exchange Algorithm (KEA)
By Carlton J. O’Riley
1.0 Introduction
This report covers my implementation of the Skipjack algorithm and Key Exchange Algorithms in C using some assembly code routines, if necessary, to optimize the encryption and decryption speeds. Then this implementation is compared to the speed of encryption and decryption for optimized DES implementations available. The Key Exchange Algorithm (KEA) is implemented to be compatible with those used by the FORTEZZA card.
The development was conducted on a Pentium II using GNU C under Red Hat Linux 5.2. The optimized implementation is written in C and is portable across many platforms. The standard C libraries are sufficient for implementing the Skipjack encryption and decryption algorithms. However, in order to implement the KEA they require a library to generate large prime numbers as well as large random numbers. For operations on these large numbers I chose to use the SSLeay libraries. They contain header files and a binary library that can be linked with the final object file to provide functions to perform the above operations.
2.0 Overview
This section covers an overview of the SKIPJACK algorithm as well as the Key Exchange Algorithm. Each of the stages of the SKIPJACK encryption and decryption algorithms will be given in detail. Followed by a detailed description of the store and forward KEA for exchanging files or email with another user. Implementations on the FORTEZZA card are also covered.
2.1 SKIPJACK Algorithm
SKIPJACK operates on a single 64-bit input, as four 16-bit words, producing a 64-bit output using an 80-bit cryptovariable (key). The algorithm works by alternating between two stepping rules (A and B) described below. Each rule is executed eight times before alternating, and there are two alternations for a total of 32 rounds. Each of these stepping rules uses a counter that is initialized with a value of 1 for encryption and 32 for decryption. Both of the stepping rules are reversible functions, allowing for decryption.
2.1.1 Stepping Rule A
The basic structure of the stepping rule A for encryption is given below (the G permutation function is covered later).
a. G permutes w 1 , b. the new w 1 is the exclusive or of the G output, the counter, and w 4 , c. words w 2 and w 3 shift one register to the right; i.e. become w 3 and w 4 respectively, d. the new w 2 is the G output e. the counter is incremented by one
The equations for this rule are shown below. The superscript is the counter value:
Encryption Decryption
w 1 k^ +^1 = Gk ( w 1 k ) ⊕ w 4 k ⊕ counterk w k^ [ G k ] ( wk )
2
1 1 1 1
− −^ −
w 2 k^ +^1 = Gk ( w 1 k ) w 2 k^ −^1 = w 3 k
wk w^ k
2
1
+ w k wk
4
1
−
wk w^ k
3
1
1 4
wk^ −^ = wk ⊕ wk ⊕ counterk^ −
1
k + k
counter counter 1
1
k − k
counter counter
2.1.2 Stepping Rule B
The basic structure of the stepping rule B for encryption is given below (the G permutation function is covered later).
a. G permutes w 1 , b. words w 3 and w 4 shift one register to the right; i.e. become w 4 and w 1 respectively, c. the new w 3 is the exclusive or of w 1 , the counter, and w 2 , d. the new w 2 is the G output e. the counter is incremented by one
The equations for this rule are shown below. The superscript is the counter value:
Encryption Decryption
wk w^ k
4
1
w k^ [ G k ] ( wk 2 )
1 1 1 1
− −^ −
w 2 k^ +^1 = Gk ( w 1 k ) [ ] ( ) 1
2 3
1 1 1 2
wk^ −^ = Gk − − wk ⊕ wk ⊕ counterk^ −
wk + = wk ⊕ wk ⊕ counter^ k
1 2
1 3
w k^ w^ k
4
1
−
wk w^ k
3
1
+ w k wk
1
1
−
counter k^ +^1 = counterk + 1 counterk^ −^1 = counterk − 1
2.1.5 F Table
The SKIPJACK F-table is shown below in hexadecimal notation. The upper 4 bits of the input index the row and the lower 4 bits index the column. For example, F(6D) = 98.
x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 0x a3 d7 09 83 f8 48 f6 f4 b3 21 15 78 99 b1 af f 1x e7 2d 4d 8a ce 4c ca 2e 52 95 d9 1e 4e 38 44 28 2x 0a df 02 a0 17 f1 60 68 12 b7 7a c3 e9 fa 3d 53 3x 96 84 6b ba f2 63 9a 19 7c ae e5 f5 f7 16 6a a 4x 39 b6 7b 0f c1 93 81 1b ee b4 1a ea d0 91 2f b 5x 55 b9 da 85 3f 41 bf e0 5a 58 80 5f 66 0b d8 90 6x 35 d5 c0 a7 33 06 65 69 45 00 94 56 6d 98 9b 76 7x 97 fc b2 c2 b0 fe db 20 e1 eb d6 e4 dd 47 4a 1d 8x 42 ed 9e 6e 49 3c cd 43 27 d2 07 d4 de c7 67 18 9x 89 cb 30 1f 8d c6 8f aa c8 74 dc c9 5d 5c 31 a Ax 70 88 61 2c 9f 0d 2b 87 50 82 54 64 26 7d 03 40 Bx 34 4b 1c 73 d1 c4 fd 3b cc fb 7f ab e6 3e 5b a Cx ad 04 23 9c 14 51 22 f0 29 79 71 7e ff 8c 0e e Dx 0c ef bc 72 75 6f 37 a1 ec d3 8e 62 8b 86 10 e Ex 08 77 11 be 92 4f 24 c5 32 36 9d cf f3 a6 bb ac Fx 5e 6c a9 13 57 25 b5 e3 bd a8 3a 01 05 59 2a 46
2.2 SKIPJACK Modes of Operation
SKIPJACK can be used in four modes of operation, which is a subset of the FIPS-81 description of modes of operation for DES. These include Output Feedback (OFB) modes, Cipher Feedback (CFB) modes, Codebook, and Cipher-block Chaining (CBC). The FORTEZZA card implements the Codebook and CBC modes of operation for SKIPJACK.
2.3 Key Exchange Algorithm
The KEA requires that each user have a private and public key, where the public key is available to both sender and receiver. There is no mention of how an end user is to validate the public keys of other users, however typical implementations use X.509 certificates. The private key of a user consists of 4 parameters: p 1024-bit prime modulus q 160-bit prime divisor of p-1 for public component checking g 1024-bit base for the exponentiation, element of order q in the multiplicative group mod p. x 160-bit user secret number (0 < x < q)
2.3.1.2 Receiver Algorithm
The first step is to obtain the public key of the sender and validate its authenticity as well as the public random number generated by the sender. The next step is to verify the public key and random number is from a user on the network, by checking that the following equations are satisfied:
1 < Y (^) A , RA < p and ( Y ) p
q A ≡^1 mod and^ (^ R^ )^ p
q
A ≡^1 mod
Next the following values are computed:
t ( R ) B^ p gAB p
x rx
BA = A mod^ = mod
u ( Y ) B^ p g AB p
x xx
AB = A mod^ = mod
w = ( tAB + uAB ) mod p
If, w ≠ 0 , then w is split into two different sections:
( )
80
1 102480 mod^2
w
v and 2 ( 1024160 ) mod 280
w
v
Which is equivalent to saying that v 1 is the upper most 80 bits of w and v 2 is the penultimate upper 80 bits of w.
They key is then calculated using:
( )
⊕
⊕ ⊕
16 48 2
64 16
2 64 16
16 2 mod 2
mod 2
mod 2
1
1 1 v
v
E
v
Key E E
v pad
v pad v pad
The pad used above is defined as 72f1a87e92824198ab0b hex. Schematically, this is represented by:
2.3.2 FORTEZZA KEA
The key generated by the KEA is not used directly to encrypt the information being sent the receiver. Rather a temporary message encryption key (MEK) is generated instead and used to encrypt the message. Then the key generated by the KEA, called a temporary encryption key (TEK) is used to encrypt the MEK. This encryption process is known as wrapping the MEK. There are no published details on the algorithm used to wrap the MEK. The implementation used by me is to pad the MEK with six bytes of 06 (hexadecimal) to produce a 128-bit input. Which is then encrypted with SKIPJACK using the TEK for a key as two separate 64-bit blocks in the Codebook mode. What is important to notice is that to send a large file to multiple users it is only necessary to encrypt the large file once.
The FORTEZZA card uses the CBC mode for encryption, which requires a 64-bit initialization vector. Therefore, the information that needs to be sent to the receiver, along with the encrypted file, includes the wrapped MEK, the public random number, and the initialization vector. This is assuming that both parties have the public key of the
The most noticeable optimization possible was to precompute combinations of each byte of the key with possible inputs to the F-table function. This is because the input to the F-table function is the exclusive or of any possible byte with a single byte of the key. Therefore, a table can be created which contains the 256 possible outputs of the F-table based on a single byte of the key. This will save four XOR instructions per step or 128 XOR instructions over a single encryption of a 64-bit block.
3.2 Memory Management
The stepping rules involve moving each 16-bit word to one place to the right each step. This is extremely slow and wasteful. It is possible to leave each 16-bit word in place and just change the operations around so that it is not necessary to perform 4 MOV instructions per step.
Also, it was noticed that the Intel instruction set has only 4 general purpose registers EAX, EBX, ECX, and EDX, however penalties are incurred for using the ECX and EDX registers for mathematical operations. This does not leave enough registers to load all four 16-bit words into registers to optimize the speed at which functions can be performed upon the data. Another, subtle optimization, is one in which pointers are used to manipulate the data directly in memory and not to copy them into local variables.
3.3 Macros vs. Subroutines
The second biggest optimization comes from inlining the G and G-1^ functions rather than subroutines. Subroutines require a lot of overheard to pass parameters and push the new instruction pointer on the stack. Therefore, by explicitly defining each step saves an enormous amount of time.
#define G(k0,k1,k2,k3,g1,g2,g5,g6) g5 = KeySchedTable[k0][g2]^g1; g6 = KeySchedTable[k1][g5]^g2; g5 = KeySchedTable[k2][g6]^g5; g6 = KeySchedTable[k3][g5]^g6;
#define INV_G(k0,k1,k2,k3,g5,g6,g1,g2) g2 = KeySchedTable[k3][g5]^g6; g1 = KeySchedTable[k2][g2]^g5; g2 = KeySchedTable[k1][g1]^g2; g1 = KeySchedTable[k0][g2]^g1;
3.4 Compiler Optimizations
This is the most machine dependent part of the optimization process. The compiler used was gcc on Red Hat Linux 5.2. The processor used is a Pentium II 233 MHz machine. The command line to compile the optimized SKIPJACK routines is:
egcs -s -static -Wall -O3 -fomit-frame-pointer -funroll-loops -malign-loops= -malign-functions=2 -malign-jumps=2 -mpentiumpro -o kea kea.c optsjlib.c kealib.c -lcrypto
It is due to these compiler optimizations that the code generated is optimized greatly. Each round produces approximately 15 lines of assembly, which uses commands that do not suffer from penalties of using registers outside of the EAX and EBX.
3.5 Comparison with Optimized DES
For the optimized version of DES I used the SSLeay libraries implementation of DES. The SSLeay libraries use an extremely fast byte lookup implementation. To compare the two implementations a 64-bit test vector was used and two different keys, since DES requires a 56-bit key and SKIPJACK requires an 80-bit key. Both implementations
precompute key-scheduling values, therefore the timing is only for the encryption and decryption routines. In order to be able to get comparable values 100,000 encryptions and decryptions are performed and timed. The results are shown in the following table (average time to perform 100,000 iterations):
Encryption Decryption SKIPJACK 34 ms 29 ms DES 16 ms 16 ms
From a simple comparison standpoint the DES algorithm consists of 16 rounds, whereas SKIPJACK is 32 rounds. It is conceivable then, that an optimized version of SKIPJACK would be twice as slow as that for DES. Using this simple comparison method, then the optimized version of SKIPJACK that I implemented is on target.
4.0 KEA Implementation
This section covers the KEA implemented to transfer a file (or E-Mail) to another user on a network. It was desired to create a KEA that is compatible with the FORTEZZA PCMCIA security cards. However, since access to these cards was not available all the data that would normally be contained on the card is stored in text files. Also for some of the internal routines to the card, for which algorithms were not available from the FORTEZZA Application Developer’s Guide, a best guess implementation was used.
The KEA operates on numbers that are on the order of 1024 bits and therefore require a large number library to perform these functions. I used the SSLeay big number libraries for this purpose.
4.1 Public Key File
This is a simple text file that contains the 1024-bit public keys of users on the network. The format of the file is a unique identifier followed by an equal sign and then the users public key in hexadecimal format. Each record is kept on a separate line. This file is named public.key.
ALICE=2D29ECD02E3497A67222D8DEBC286131D149F4581B3E586D0151024C02E8B23DA09A E2CA5ED1A4B2D772562316E4D2804D226788284ED655CF54610D38F66FAB1A0A2E2D3C 901D9758D566722AFF1F734B2ADBD2B67F1300CE455F00968CA791A8767867363D7D49EE74A DC349D9FDFDB96B01F0FC1F0690EC BOB=7730D4BBF3A2EFDB218E70413E86102014CEC06C205F5419293B65C69A971E5455EB79A0B DB90AB214C5240EDE6CFDD58C7C19C5269D57DFF60B61C1DB2FF64864BEE51987F270034BC AD731682095E42608C3D7987F9649FBF716887633EB574B39CC73DF89951FC1BD6D3889D48FE 244B829AFD40506AB9221BA562C
4.2 Private Key File
This is a text file containing the 4 components of a user’s private key. The user’s secret number ( x ), p , q , and g. Each component is on a separate line labeled by either X, P, Q, or G, an equal sign and the value in hexadecimal. This is stored in the file private.key.
X=62319AC47DE145180ABD322C59E2B6002781E P=9D4C6E6D42EA91C828D67D4994A9F01B8E5B5B730D0FAAE7BD569DD1914E3AD4759C805331E DA1459FB56BE8A8DE4736652A82B276E82ACD63F5B78D0B75A03EB34D397DBE7B37408F72136A CB0879FE61C718A37F5154B5078A7649FB3D4FB4C481E01062C5241F229FA580423368DD DBF25351F0C5800DE05B92BA6A Q=97AD85FD2B371ED069818AB3C6EE8773D9DB029D G=595D3443EC897C8251E5FA9D02AB8B75C0FC57B0969F880DA366A10001912A0196BCB81C41A C8485031AC598B5481EAE2726B719D8D9915A6105973472386C0A6A2C732CD6700D341F54BF
