In This chapter:
Advanced Wireless Technologies, Inc.
Each chip contains the following registers. They are addressed as specified in Figure 2-1.
Ciphertext0 (64 bits = 8 bytes)
The value of the first ciphertext being searched. Ciphertext0 is identical in all search units and is set only once (when the search system is first initialized).
Ciphertext1 (64 bits = 8 bytes)
The value of the second ciphertext being searched. Ciphertext1 is identical in all search units and is set only once (when the search system is first initialized).
PlaintextByteMask (8 bits)
The plaintext byte selector. One-bits in this register indicate plaintext bytes that should be ignored when deciding whether or not the plaintext produced by a particular key is possibly correct. This mask is helpful when only a portion of the plaintext's value is known. For example, if the first S bytes equal a known header but the remaining three are unknown, a PlaintextByteMask of 0x07 would be used.
PlaintextXorMask (64 bits = 8 bytes)
This register is XORed with decryption of ciphertext0. This is normally filled with
Figure 2-1: Register Addressing
Register(s) Description & Comments 0x00-0x1F PlaintextVector 0x20-0x27 PlaintextXorMask 0x28-0x2F Ciphertext0 0x30-0x37 Ciphertext1 0x38 PlaintextByteMask 0x39-0x3E Unused (reserved) 0x3F SearchInfo 0x40-0x47 Search unit 0 key counter (0x40-0x46) and SearchStatus (0x47) 0x48-0x4F Search unit 1 key counter (0x48-0x4E) and SearchStatus (0x4F) 0x50-0x57 Search unit 2 key counter (0x50-0x56) and SearchStatus (0x57) 0x58-0x5F Search unit 3 key counter (0x58-0x5E) and SearchStatus (0x5F) 0x60-0x67 Search unit 4 key counter (0x60 0x66) and SearchStatus (0x67) 0x68-0x6F Search unit 5 key counter (0x68 0x6E) and SearchStatus (0x6F) 0x70-0x77 Search unit 6 key counter (0x70-0x76) and SearchStatus (0x77) 0x78-0x7F Search unit 7 key counter (0x78-0x7E) and SearchStatus (0x7F) 0x80-0x87 Search unit 8 key counter (0x80-0x86) and SearchStatus (0x87) 0x88-0x8F Search unit 9 key counter (0x88 0x8E) and SearchStatus (0x8F) 0x90-0x97 Search unit 10 key counter (0x90-0x96) and SearchStatus (0x97) 0x98-0x9F Search unit 11 key counter (0x98-0x9E) and SearchStatus (0x9F) 0xA0-0xA7 Search unit 12 key counter (0xA0-0xA6) and SearchStatus (0xA7) 0xA8-0xAF Search unit 13 key counter (0xA8-0xAE) and SearchStatus (0xAF) 0xB0-0xB7 Search unit 14 key counter (0xB0 0xB6) and SearchStatus (0xB7) 0xB8-0xBF Search unit 15 key counter (0xB8-0xBE) and SearchStatus (0xBF) 0xC0-0xC7 Search unit 16 key counter (0xC0-0xC6) and SearchStatus (0xC7) 0xC8-0xCF Search unit 17 key counter (0xC8-0xCE) and SearchStatus (0xCF) 0xD0-0xD7 Search unit 18 key counter (0xD0-0xD6) and SearchStatus (0xD7) 0xD8-0xDF Search unit 19 key counter (0xD8-0xDE) and SearchStatus (0xDF) 0xE0-0xE7 Search unit 20 key counter (0xE0-0xE6) and SearchStatus (0xE7) 0xE8 0xEF Search unit 21 key counter (0xE8-0xEE) and SearchStatus (0xEF) 0xF0-0xF7 Search unit 22 key counter (0xF0-0xF6) and SearchStatus (0xF7) 0xF8-0xFF Search unit 23 key counter (0xF8-0xFE) and SearchStatus (0xFF)
the CBC mode IV.
PlaintextVector (256 bits = 8 bytes)
Identifies allowable plaintext byte values (ignoring those masked by the PlaintextByteMask). If, for any plaintext byte P[i=0..7], bit P[i] is not set, the decryption key will be rejected. PlaintextVector is identical in all search units and is set only once (when the search system is first initialized).
SearchInfo (8 bits)
The bits in SearchInfo describe how the correct plaintext identification function works. Bits of SearchInfo are defined as follows:
bit 0 = UseCBC
If this bit is set, Ciphertext0 is XORed onto the plaintext produced by decrypting Ciphertext1 before the plaintext is checked. This bit is used when checking CBC-mode ciphertexts.
bit 1 = ExtraXOR
If set, the right half of the resulting plaintext is XORed onto the left before any plaintext checking is done. ExtraXOR and UseCBC cannot be used together.
bit 2 = ChipAllActive
If cleared, one or more search units in this chip have halted (e.g., SearchActive is zero). This value is computed by ANDing the SearchActive bits of all search units' SearchStatus bytes. The inverse of this value is sent out on a dedicated pin, for use in driving a status LED which lights up whenever the chip halts.
bit 3 = BoardAllActive
This pin is the AND of the ChipAllActive lines of this chip and all later chips on the board. This is implemented by having each chip n take in chip n+1's BoardAllActive line, AND it with its own ChipAllActive line, and output the result to chip n-1 for its BoardAllActive computation. This makes it possible to find which chip on a board has halted by querying log2N chips, where N is the number of chips on the board. If BoardAllActiveEnable is not set to 1, BoardAllActive simply equals the BoardAllActiveInput pin, regardless of the chip's internal state.
bit 4 = BoardAllActiveEnable
If this value is set to 0 then BoardAllActive always equals the BoardAllActiveInput pin, regardless of whether all search units on the board are active. If this bit is set to 1, then the BoardAllActive register (and output) are set to reflect the internal state of the chip ANDed with the input pin.
bits 5-7 = Unused
KeyCounter (56 bits)
The value of the key currently being checked The KeyCounter is updated very frequently (i.e., once per key tested). A unique KeyCounter value is assigned to every search unit. When the search unit halts after a match, KeyCounter has already been incremented to the next key; the match was on the previous key.
SearchCommandAndStatus (8 bits)
The bits in SearchStatus describe the current search state of a specific search unit. A unique SearchStatus register is allocated for each search unit. Bits of SearchStatus are allocated as follows:
bit 0 = SearchActive
Indicates whether the search is currently halted (0=halted, 1=active). The computer sets this bit to begin a search, and it is cleared by the search unit if a matching candidate key is found. The host computer checks the status of this bit periodically and, if it is zero, reads out the key then restarts the search. (See also ChipAllActive and BoardAllActive in the SearchInfo register.)
bit 1 = CiphertextSelector
Indicates whether the search engine is currently checking Ciphertext0 or Ciphertext1. (0=Ciphertext0, 1=Ciphertext1). If this bit is clear, the search engine decrypts Ciphertext0 and either sets CiphertextSelector to 1 (if the plaintext passes the checks) or increments KeyCounter (if the plaintext does not pass). If this bit is set, the search engine decrypts Ciphertext1 and either sets SearchActive to 0 (if the plaintext passes the checks) or sets CiphertextSelector to 0 and increments KeyCounter (if the plaintext does not pass).
bits 2-7 = Unused
In order to be able to address each search unit separately, each can be addressed uniquely by the combination of its location on the chip, the location of the chip on the board, and board's identifier. The BoardID is interpreted off-chip; each chip has a board select pin, which notifies the chip when the board has been selected. Chip ID matching is done inside each ASIC; the ID pins of the ASIC are wired to the chip's ID.
All commands are originated by the computer go via a bus which carries 8 bits for BoardID/ChipID/Register address, 8 bits for data, and a few additional bits for controls .
To do a search, the host computer will program the search units as shown in Figure 2-2. (N is the total number of search units, numbered from 0 to N-1, each with a unique BoardID/ChipID/Register address.)
Each search unit contains a DES engine, which performs DES on two 32-bit registers L/R using the key value in KeyCounter. Each search unit goes through the process detailed in Figure 2-3, and never needs to halt. If registers are updated during the middle of this process, the output is meaningless (which is fine, since an incorrect output is statistically almost certain to not be a match).
Figure 2-2: Example algorithm for programming
This is a very simple algorithm intended only as an example. The actual software will use more intelligent search techniques, using the BoardAllActive and ChipAllActive lines.
Load Ciphertext0, Ciphertext1, PlaintextXorMask, PlaintextByteMask, PlaintextVector, and SearchInfo into each chip.
For i = 0 upto N-1
Set SearchStatus in search unit i to 0 while loading the key.
While correct key has not been found:
For i = 0 upto N-1:Read SearchStatus from search unit i.
This section describes how the system will be programmed for some typical operations.
Known ciphertext/plaintext (ECB, CBC, etc.)
If a complete ciphertext/plaintext block is known, this mode is used. This works for most DES modes (ECB, CBC, counter, etc.), but does require a full plaintext/ ciphertext pair.
For this search, there are 8 (or fewer) unique plaintext bytes in the known plaintext. The bits corresponding to these bytes are set in PlaintextVector, but all other bits are set to 0.
Figure 2-3: Search unit operation
1. If CiphertextSelector is 0, then Let L/R = Ciphertext0.
2. Decrypt L/R using the key in KeyCounter, producing a candidate plaintext in L/R.
3. If ExtraXOR is 1, then Let L = L XOR R.
Let L/R = L/R XOR PlaintextXorMask.
If CiphertextSelector is 1 and UseCBC is 1, then:
Let L/R = L/R XOR Ciphertext0.
4. If SearchActive = 1 AND (
Let CiphertextSelector = 0.
If CiphertextSelector is 1 then Let SearchActive = 0.
5. Go to step 1.
Equals the ciphertext block.
Equals the ciphertext block.
UseCBC and ExtraXOR are both set to 0.
Set to 0x00 (all bytes used).
Set to 0x0000000000000000.
Because the plaintext byte order does not matter, there are 8 acceptable values for each ciphertext byte, or 88 = 224 = 16.7 million possible ciphertexts which will satisfy the search criteria. The probability that an incorrect ciphertext will pass is 224 / 264, so over a search of 255 keys there will be an average of (255)( 224 / 264), or 32768 false positives which will need to be rejected by the controlling computer. Because the Ciphertext0 and Ciphertext1 selections are identical, any false positives that pass the first test will also pass the second test. (The performance penalty is negligible; the search system will do two DES operations on each of the 32768 false positive keys, but only one DES operation on all other incorrect keys.)
ASCII text (ECB or CBC)
A minimum of two adjacent ciphertexts (16 bytes total) are required for ASCII-only attacks.
Set only the bits containing acceptable ASCII characters. For normal text, this would normally include 55 of the 256 possible characters occur (10=line feed, 13=carriage return, 32=space, 65-90=capital letters, and 97-122=lowercase letters).
Equals the first ciphertext.
Equals the second ciphertext.
UseCBC is set to 0 if ECB, or set to 1 if the ciphertext was produced using CBC. ExtraXOR is set to 0.
Set to 0x00 (all bytes used).
Set to 0x0000000000000000 for ECB, to IV for CBC.
The probability that the two (random) candidate plaintexts produced by an incorrect key will contain only the ASCII text characters listed above is (55/256)16. In a search, there will thus be an average of 255 (55/256)16 = 742358 false positives which need to be rejected by the computer. For one key in about 220,000, the first check will pass and an extra DES will be required. (The time for these extra DES operations is insignificant.) Idle time lost while waiting for false positives to be cleared is also insignificant. If the computer checks each search unit's SearchActive flag once per second, a total of 0.5 search unit seconds will be wasted for every
false positive, or a total of 103 search-unit hours, out of about 4 million search-unit hours for the whole search.
When programming CBC mode, note that the PlaintextXorMask must be set to the IV (or the previous ciphertext, if the ciphertext being attacked is not in the first block).
Matt Blaze's Challenge
The goal is to find a case where all plaintext bytes are equal and all ciphertext bytes are equal.
Set only bit 0.
Set to a fixed value with all bytes equal
Same as Ciphertext0.
UseCBC is set to 0. ExtraXOR is set to 1.
Set to 0x0F (only left half examined).
Set to 0x0000000000000000.
If the right and left half are equal, as must be the case if all plaintext bytes are the same, then when the ExtraXOR bit's status causes the L=L XOR R step, L will become equal to 0. The plaintext byte mask selects only the left half and the PlaintextVector makes sure the 4 bytes are 0.
False positives occur whenever L=R, or with one key in 232. Because this search is not guaranteed to terminate after 256 operations, the average time is 256 (not 255). The number of false positives is expected to be 256 / 232 = 224 = 16.8 million. Each search unit will thus find a false positive every 232 keys on average, or about once every half hour. At 1 second polling of search units, (0.5)(16.8 million)/3600 = 2333 search unit hours will be idle (still under 1% of the total). The host computer will need to do the 16.8 million DES operations (on average), but even a fairly poor DES implementation can do this in just a few minutes.
The architecture was intended to find DES keys in less than 10 days on average. The performance of the initial implementation is specified in Figure 2-4. Faster results can be easily obtained with increased hardware; doubling the amount of hardware will halve the time per result. Within the design, boards of keysearch ASICs can be added and removed easily, making it simple to make smaller or larger systems, where larger systems cost more but find results more quickly. Larger systems will have additional power and cooling requirements.
Figure 2-4: Performance Estimate
Cryptography Research will write the following software:
Cryptography Research will develop software to generate test vectors for the chip for testing before the design is sent to the fab. This software will test all features on the chip and all modes of operation. This program will have a simple command line interface.
The host computer software program will implement the standard search tasks of breaking a known plaintexts, breaking encrypted ASCII text (ECB and CBC modes), and solving the Matt Blaze challenge. These programs will be written in
standard ANSI C, except for platform-specific I/O code. The host program will also have a test mode, which loads search units with tasks that are known to halt reasonably quickly (e.g., after searching a few million keys) and verifies the results to detect of any failed parts. (The software will include the capability of bypassing bad search units during search operations.) Users who wish to perform unusual searches will need to add a custom function to determining whether candidate keys are actually correct and recompile the code.
The initial version of this program will have a simple command line interface and will be written for DOS. A Linux port will also be written, but may not be ready by the initial target completion date. (Because the only platform-specific code will be the I/O functions, it should be very easy to port to any platform with an appropriate compiler.) Software programs will identify the participants in the project (AWT, EFF, and Cryptography Research).
Cryptography Research will also produce a version with a prettier user interface to make the demonstration more elegant (platform-to-be-determined).
All software and source code will be placed in the public domain.
An 8-bit identifier unique for each board. This will be set with a DIP switch on the board. The host computer addresses chips by their ChipID and BoardID.
A DES mode in which the first plaintext block is XORed with an initialization vector (IV) prior to encryption, and each subsequent plaintext is XOR with the previous ciphertext.
A value used by the host computer to specify which chip on a board is being addressed.
The first of the two ciphertexts to be attacked.
The second of the two ciphertexts to be attacked.
Pre-ANSI C can be supported if required. Any GUI code will probably be written in C++ .
A register used to select the current ciphertext being attacked. The selector is needed because a single DES engine needs to be able to test two ciphertexts to determine whether both are acceptable matches before deciding that a key is good match.
The Data Encryption Standard.
A register to make the search units perform an extra operation which XORs the right and left halves of the result together. This is used to add support for Matt Blaze's DES challenge.
The computer that controls the DES search array.
Each search unit has a KeyCounter register which contains the current key being searched. These registers are each 7 bytes long, to hold a 56-bit key.
Unencrypted data corresponding to a ciphertext.
An 8-bit register used to mask off plaintext bytes. This is used to mask off bytes in the plaintext whose values aren't known or are too variable to list in the PlaintextVector.
A 256-bit register used to specify which byte values can be present in valid plaintexts. It is the host computer's responsibility to ensure that only a reasonable number of bits are set in the PlaintextVector; setting too many will cause the DES search units to halt too frequently.
A 64-bit register XORed onto the value derived by decrypting ciphertext 0. Normally this mask is either zero or set to the CBC mode initialization vector (IV).
A bit for each search unit which indicates whether it is currently searching, or whether it has stopped at a candidate key. Stopped search units can be restarted by loading a key which does not halt and resetting this bit.
A register containing miscellaneous information about how DES results should be post- processed and also indicating whether any search units on the chip or on the
board have halted.
A bit in SearchInfo which directs the search engine to do CBC-mode post-processing after decryption (e.g., XOR the decryption of ciphertext1 with ciphertext0 to produce plaintext1).