We propose to design an double-key encryption chip that will accept an eight bit wide input serially and will output the encrypted data serially. In addition, we will have a number of control lines that will allow the user to change the encryption keys in the chip and to choose which key to use for encryption, among other things.
Our plans are necessarily rather embrionic at this stage because we do not currently know enough about encryption to propose a specific encryption algorithm that would be feasible for a project of this magnitude. However, we are conceptually familiar with double-key encryption: in double key encryption, one key is used as the seed by which clear text is converted into encrypted text and the other key is used to convert encrypted text into clear text. The keys are symmetrical in the sense that either can encrypt or decrypt, so long as the other performs the opposite process. Our idea is to store both 8- to 12-bit keys in two user-accessable registers: the user would be able to decide what the keys should be and would be able to change them (we would, of course, have some measure of security for changing the keys; for example, in order to change a key, the user should probably have to provide the old key to prove that he is not just some randomly destruc- tivel individual. This would, of course, be inadequate in the real world, but a chip of this scale would not be produced in the real world, either.). Since it is not very useful to encrypt a byte of data at a time, we propose to do encryption eight bytes at a time: the user would input eight bytes, the chip would encrypt the data and would spit out however many bytes the encrypted data amounted to. Obviously, since we only have 34 available pins, eight byte wide input and output is not feasible, so we propose to do the input and the output serially: the user would input a byte of data for each clock cycle, the chip would encrypt the data once all of it had been inputted, and the encrypted text would be outputted serially, a byte for each clock cycle.
Doing what we propose should be feasible. We require eight input pins, eight output pins, one clock pin, and probably around four control pins; for a total of 21 pins, which is less than the allowable 34. We would need eight registers to latch the input data, eight registers to latch the out- put data, two registers for the input to the encryption ALU, one register for the output of the ALU, up to three registers for the encryption/decryption keys, and a half register (4 bits) for the the con- trol signals. This adds up to 22.5 registers; since a register takes up approximately 28000 square microns of chip space, we would need 630000 square microns for the registers. Assuming that the ALU would take up about 100000 square microns and that the total area available to us for use is 3240000 square microns (both figures that you gave us), this would leave us with 2510000 square microns for control and routing (or perhaps more ALUs to speed up encryption), and this amount of space seems sufficient.
September 12, 1995