DES calls for a 56-bit key operating on 64-bit blocks of data at one time. It operates in Electronic Codebook (ECB) Mode, meaning that the encryption of a block of text depends only on the text and on the key; previous or subsequent blocks of text do not effect the encryption at all. This means, of course, that this algorithm is less secure than other non-ECB algorithms, but for a project of this scale, it really is not feasible to use non-ECB algorithms due to the increased amount of data that must be stored. DES takes the input data and permutes it bit-by-bit. It then splits the permuted data into 2 halves, performs 16 rounds of encryption on each half, and reunites the two halves at teh end of the sixteenth round. The cyphertext then undergoes a permutation symmetric to the input permutation, and this result is outputted.
Each round of encryption consists of four steps. In the first step, the bits of the key are shifted and 48 of them are selected. These selected key bits are then XORed with the bits of the right half of the data, permuted and expanded into 48 bits. The result is reduced to 32 bits obtained from a look-up table, and these 32 bits are permuted. The result of this operation is XORed with the left half, and the result becomes the new left half. The old left half becomes the new right half.
All that need be done to decrypt data that was encrypted using the DES algorithm is to reverse the order that the keys are used in the 16 rounds of encryption. In other words, if k1 is the 48-bit key obtained from the 56-bit key for the first round of encryption, k2 the key for the second round, and so on, when we want to decrypt, we use k16 first, then k15 and so on down to k1.
Due to the size constraints of out chip and the limitations of the register cells that we will be using, it is clearly not feasible for us to use the DES algorithm in full. Rather, we propose to use a scaled-down version of it. Specifically, we propose to use a 16-bit key to encrypt 16-bit blocks of data (entered serially by byte). We realize that using a 16-bit key means that there will only be 65536 possible keys, meaning that a brute-force attack on our encryption scheme will probably succeed in less than a minute. However, we see no alternative to this given the size and design constraints that we will be operating under.
In addition to the key and data size reductions, we propose to make a few other modifications to the DES algorithm. We do not feel that it would be a good idea to duplicate DES's table look-up scheme for bit selection, so our bit selection will be an arithmetic function the encryption round and the 24-bit intermediate block of encrypted data. We have not determined what this arithmetic function will be (we'll have to give this more thought to ensure that it is fully reversible to allow for decryption), but it will necessitate the use of an ALU, another desireable component for this project. Finally, due to speed concerns, we may not want to have sixteen rounds of encryption. We plan to do eight passes; this number will be less tedious than sixteen and it will not really have much effect on the complexity of the design.
The principal necessary components necessary to complete this project are a) 2 input registers; b) 2 output registers; c) 2 key registers; d) 4-6 intermediate processing registers; e) at least 3 ALU registers; f) 1 register for latching the control signal; g) the ALU; and h) the control. Necessary. Permutations could largely be handled by routing rather than by explicit logic, except in cases when the permutation depends on the current state (i.e., what pass we're on), in which case it is a question for the control. This number of elements should certainly be small enough to fit on the chip.
As can be seen from our block diagram (this is currently only available on paper but will be available online as soon as we can figure how to do it so that it looks nice), we are planning to have a more sophisticated control than is really necessary. There will be three possible modes that the chip will work in: 1) Key changing mode; 2) Encryption mode; and 3) Decryption mode. The control unit must decode the control inputs so that the chip is put into the correct mode. In addition, all input and output will be done serially by byte; this adds another level of complexity to the control. Finally, while it would be possible to do all of the encryption and decryption in a pipeline fashion, we are specifying that the results of each stage of encryption and decryption will appear in the intermediate registers ONLY at the completion of a given encryption stage. When combined with the fact that we will make 8 discrete encryption or decryption passes for each block of data processed, necessitating that the control keep track of what pass we are on and select the correct bits of the key accordingly, this makes for a control that is significantly more sophisticated than would appear necessary at first blush.
Unfortunately for us, it is not intuitively obvious what the correct output of an encrytion operation should be. In other words, it will not be obvious whether the two bytes that our chip spits out are correctly encrypted. However, one of the wonderful features of this form of encryption is that it lends itself naturally to both hardware and software implementation. We plan to write a C program that will encrypt a two-byte input according to the algorithm that we propose to use for the chip. We will format the output from this program so that it matches the output from IRSIM and other simulation tools, allowing us to do a DIFF to determine if the chip design is producing correct output.
Information Source: Bruce Schneier, Applied Cryptography: Protocols, Algorithms, and Source Code in C , (New York: John Wiley & Sons, Inc., 1994), pp. 219-243.
September 12, 1995