chap-2.html
8b69717ce9b82a592ac6327083774f410a36a3c0fb60f37089b2a0487cfac892<!DOCTYPE HTML PUBLIC "html.dtd">
<HTML>
<HEAD>
<TITLE>Cracking DES: Secrets of Encryption Research, Wiretap Politics, and
Chip Design </TITLE>
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>
<A NAME="2">2</A>
</H1>
<H2>
<I>Design for DES Key Search Array </I>
</H2>
<P>
<P>
<I>In This chapter: </I>
<P>
<UL>
<LI>
<I>On-Chip Registers </I>
</UL>
<UL>
<LI>
<I>Commands </I>
</UL>
<UL>
<LI>
<I>Search Unit Operation </I>
</UL>
<UL>
<LI>
<I>Sample Programming Descriptions </I>
</UL>
<UL>
<LI>
<I>Scalability and Performance </I>
</UL>
<UL>
<LI>
<I>Host Computer Software </I>
</UL>
<UL>
<LI>
<I>Glossary </I>
</UL>
<P>
Cryptography Research <BR>
and <BR>
Advanced Wireless Technologies, Inc. <BR>
<H3>
<I>On-Chip Registers </I>
</H3>
<P>
Each chip contains the following registers. They are addressed as specified
in Figure 2-1.
<P>
<B>Ciphertext0 (64 bits = 8 bytes) </B>
<P>
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).
<P>
<B>Ciphertext1 (64 bits = 8 bytes) </B>
<P>
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).
<P>
<B>PlaintextByteMask (8 bits) </B>
<P>
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.
<P>
<B>PlaintextXorMask (64 bits = 8 bytes) </B>
<P>
This register is XORed with decryption of ciphertext0. This is normally filled
with
<P>
<I>2-1</I>
<P>
<HR>
<P>
2-2
<P>
<TABLE BORDER CELLPADDING="12">
<TR>
<TD><P ALIGN="Center">
<B><I>Figure 2-1: Register Addressing </I></B>
<PRE> 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)
</PRE>
</TD>
</TR>
</TABLE>
<P>
<P>
the CBC mode IV.
<P>
<B>PlaintextVector (256 bits = 8 bytes) </B>
<P>
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).
<P>
<B>SearchInfo (8 bits) </B>
<P>
The bits in SearchInfo describe how the correct plaintext identification
function works. Bits of SearchInfo are defined as follows:
<P>
<HR>
<P>
<I>2-3</I>
<P>
<B>bit 0 = UseCBC </B>
<P>
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.
<P>
<B>bit 1 = ExtraXOR </B>
<P>
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.
<P>
<B>bit 2 = ChipAllActive </B>
<P>
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.
<P>
<B>bit 3 = BoardAllActive </B>
<P>
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.
<P>
<B>bit 4 = BoardAllActiveEnable </B>
<P>
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.
<P>
<B>bits 5-7 = Unused </B>
<P>
<B>KeyCounter (56 bits) </B>
<P>
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.
<P>
<B>SearchCommandAndStatus (8 bits) </B>
<P>
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:
<P>
<HR>
<P>
<I>2-4</I>
<P>
<B>bit 0 = SearchActive </B>
<P>
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.)
<P>
<B>bit 1 = CiphertextSelector </B>
<P>
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).
<P>
<B>bits 2-7 = Unused</B>
<H3>
<B><I>Commands </I></B>
</H3>
<P>
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.
<P>
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 .
<P>
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.)
<H3>
<I>Search Unit Operation </I>
</H3>
<P>
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).
<P>
<HR>
<P>
<I>2-5</I>
<P>
<TABLE BORDER CELLPADDING="12">
<TR>
<TD><P ALIGN="Center">
<I><B>Figure 2-2: Example algorithm for programming <BR>
the search array using host computer </B></I>
<P>
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.
<P>
Load Ciphertext0, Ciphertext1, PlaintextXorMask, PlaintextByteMask,
PlaintextVector, and SearchInfo into each chip.
<P>
For i = 0 upto N-1
<BLOCKQUOTE>
Set SearchStatus in search unit i to 0 while loading the key. <BR>
Set KeyCounter of search unit i to ((256)(i) / N). <BR>
Set SearchStatus in search unit i to 1 to enable SearchActive.
</BLOCKQUOTE>
<P>
EndFor
<P>
While correct key has not been found:
<BLOCKQUOTE>
For i = 0 upto N-1:
<BLOCKQUOTE>
Read SearchStatus from search unit i.<BR>
Check SearchActive bit. <BR>
If SearchActive is set to 0:
<BLOCKQUOTE>
Read KeyCounter from search unit i. <BR>
Subtract 1 from the low 32 bits of the key. <BR>
Perform a DES operation at the local computer to check the key. If the key
is correct, the search is done. <BR>
Set the SearchActive bit of SearchStatus to restart the search.
</BLOCKQUOTE>
<P>
EndIf
</BLOCKQUOTE>
<P>
EndFor
</BLOCKQUOTE>
<P>
EndWhile <BR>
</TD>
</TR>
</TABLE>
<P>
<H3>
<I>Sample Programming Descriptions </I>
</H3>
<P>
This section describes how the system will be programmed for some typical
operations.
<P>
<B><I>Known ciphertext/plaintext (ECB, CBC, etc.) </I></B>
<P>
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.
<P>
<B>PlaintextVector </B>
<P>
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.
<P>
<HR>
<P>
<I>2-6</I>
<P>
<TABLE BORDER CELLPADDING="12">
<TR>
<TD><P ALIGN="Center">
<B><I>Figure 2-3: Search unit operation </I></B>
<P>
1. If CiphertextSelector is 0, then Let L/R = Ciphertext0. <BR>
If CiphertextSelector is 1, then Let L/R = Ciphertext1.
<P>
2. Decrypt L/R using the key in KeyCounter, producing a candidate plaintext
in L/R.
<P>
3. If ExtraXOR is 1, then Let L = L XOR R.<BR>
If CiphertextSelector is 0, then
<BLOCKQUOTE>
Let L/R = L/R XOR PlaintextXorMask.
</BLOCKQUOTE>
<P>
If CiphertextSelector is 1 and UseCBC is 1, then:
<BLOCKQUOTE>
Let L/R = L/R XOR Ciphertext0.
</BLOCKQUOTE>
<P>
4. If SearchActive = 1 AND ( <BR>
(PlaintextByteMask[0x80] = 0 AND PlaintextVector[byte 0 of L] is 0) OR
(PlaintextByteMask[0x40] = 0 AND PlaintextVector[byte 1 of L] is 0) OR
(PlaintextByteMask[0x20] = 0 AND PlaintextVector[byte 2 of L] is 0) OR
(PlaintextByteMask[0x10] = 0 AND PlaintextVector[byte 3 of L] is 0) OR
(PlaintextByteMask[0x08] = 0 AND PlaintextVector[byte 0 of R] is 0) OR
(PlaintextByteMask[0x04] = 0 AND PlaintextVector[byte 1 of R] is 0) OR
(PlaintextByteMask[0x02] = 0 AND PlaintextVector[byte 2 of R] is 0) OR
(PlaintextByteMask[0x01] = 0 AND PlaintextVector[byte 3 of R] is 0)) then:
<BLOCKQUOTE>
Let CiphertextSelector = 0. <BR>
Increment KeyCounter.
</BLOCKQUOTE>
<P>
else
<BLOCKQUOTE>
If CiphertextSelector is 1 then Let SearchActive = 0. <BR>
Let CiphertextSelector = 1.
</BLOCKQUOTE>
<P>
5. Go to step 1. <BR>
</TD>
</TR>
</TABLE>
<P>
<P>
<B>Ciphertext0 </B>
<P>
Equals the ciphertext block.
<P>
<B>Ciphertext1 </B>
<P>
Equals the ciphertext block.
<P>
<B>SearchInfo </B>
<P>
UseCBC and ExtraXOR are both set to 0.
<P>
<B>PlaintextByteMask </B>
<P>
Set to 0x00 (all bytes used).
<P>
<HR>
<P>
<I>2-7</I>
<P>
<B>PlaintextXorMask</B>
<P>
Set to 0x0000000000000000.
<P>
Because the plaintext byte order does not matter, there are 8 acceptable
values for each ciphertext byte, or 8<SUP>8</SUP> = 2<SUP>24</SUP> = 16.7
million possible ciphertexts which will satisfy the search criteria. The
probability that an incorrect ciphertext will pass is 2<SUP>24</SUP> /
2<SUP>64</SUP>, so over a search of 2<SUP>55</SUP> keys there will be an
average of (2<SUP>55</SUP>)( 2<SUP>24</SUP> / 2<SUP>64</SUP>), 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.)
<P>
<B><I>ASCII text (ECB or CBC) </I></B>
<P>
A minimum of two adjacent ciphertexts (16 bytes total) are required for
ASCII-only attacks.
<P>
<B>PlaintextVector </B>
<P>
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).
<P>
<B>Ciphertext0 </B>
<P>
Equals the first ciphertext.
<P>
<B>Ciphertext1 </B>
<P>
Equals the second ciphertext.
<P>
<B>SearchInfo </B>
<P>
UseCBC is set to 0 if ECB, or set to 1 if the ciphertext was produced using
CBC. ExtraXOR is set to 0.
<P>
<B>PlaintextByteMask </B>
<P>
Set to 0x00 (all bytes used).
<P>
PlaintextXorMask
<P>
Set to 0x0000000000000000 for ECB, to IV for CBC.
<P>
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)<SUP>16</SUP>. In a search, there will thus be an average of
2<SUP>55</SUP> (55/256)<SUP>16</SUP> = 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
<P>
<HR>
<P>
<I>2-8</I>
<P>
false positive, or a total of 103 search-unit hours, out of about 4 million
search-unit hours for the whole search.
<P>
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).
<P>
<B><I>Matt Blaze's Challenge </I></B>
<P>
The goal is to find a case where all plaintext bytes are equal and all ciphertext
bytes are equal.
<P>
<B>PlaintextVector </B>
<P>
Set only bit 0.
<P>
<B>Ciphertext0 </B>
<P>
Set to a fixed value with all bytes equal
<P>
<B>Ciphertext1 </B>
<P>
Same as Ciphertext0.
<P>
<B>SearchInfo </B>
<P>
UseCBC is set to 0. ExtraXOR is set to 1.
<P>
<B>PlaintextByteMask </B>
<P>
Set to 0x0F (only left half examined).
<P>
PlaintextXorMask
<P>
Set to 0x0000000000000000.
<P>
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.
<P>
False positives occur whenever L=R, or with one key in 2<SUP>32</SUP>. Because
this search is not guaranteed to terminate after 2<SUP>56</SUP> operations,
the average time is 2<SUP>56</SUP> (not 2<SUP>55</SUP>). The number of false
positives is expected to be 2<SUP>56</SUP> / 2<SUP>32</SUP> = 2<SUP>24</SUP>
= 16.8 million. Each search unit will thus find a false positive every
2<SUP>32</SUP> 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.
<P>
<HR>
<P>
<I>2-9</I>
<H3>
<I>Scalability and Performance </I>
</H3>
<P>
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.
<P>
<TABLE BORDER CELLPADDING="12">
<TR>
<TD><P ALIGN="Center">
<B><I>Figure 2-4: Performance Estimate </I></B>
<P>
<TABLE CELLPADDING="2">
<TR>
<TD>Total ASICs</TD>
<TD>1536</TD>
</TR>
<TR>
<TD>Search units per ASIC</TD>
<TD>24</TD>
</TR>
<TR>
<TD>Total search units</TD>
<TD>36864</TD>
</TR>
<TR>
<TD>Clock speed (Hz)</TD>
<TD>4.00E+07</TD>
</TR>
<TR>
<TD>Clocks per key (typical)</TD>
<TD>16</TD>
</TR>
<TR>
<TD>DES keys per search unit per second</TD>
<TD>2.50E+06</TD>
</TR>
<TR>
<TD>Total DES keys per second</TD>
<TD>9.22E+10</TD>
</TR>
<TR>
<TD COLSPAN="2">
<HR>
</TD>
</TR>
<TR>
<TD>Search size (worst case)</TD>
<TD>7.21E+16</TD>
</TR>
<TR>
<TD>Seconds per result (worst case)</TD>
<TD>7.82E+05</TD>
</TR>
<TR>
<TD>Days per result (worst case)</TD>
<TD>9.05</TD>
</TR>
<TR>
<TD COLSPAN="2">
<HR>
</TD>
</TR>
<TR>
<TD>Search size (average case)</TD>
<TD>3.60E+16</TD>
</TR>
<TR>
<TD>Seconds per result (average case)</TD>
<TD>3.91E+05</TD>
</TR>
<TR>
<TD><B>Days per result (average case) </B></TD>
<TD><B>4.52 </B></TD>
</TR>
</TABLE>
<P>
</TD>
</TR>
</TABLE>
<H3>
<I><BR>
Host Computer Software </I>
</H3>
<P>
Cryptography Research will write the following software:
<P>
<B>Simulation </B>
<P>
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.
<P>
<B>Host computer </B>
<P>
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
<P>
<HR>
<P>
<I>2-10</I>
<P>
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.
<P>
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).
<P>
Cryptography Research will also produce a version with a prettier user interface
to make the demonstration more elegant (platform-to-be-determined).
<P>
All software and source code will be placed in the public domain.
<H3>
<I>Glossary </I>
</H3>
<P>
<B>BoardID </B>
<P>
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.
<P>
<B>CBC mode </B>
<P>
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.
<P>
<B>ChipID </B>
<P>
A value used by the host computer to specify which chip on a board is being
addressed.
<P>
<B>Ciphertext </B>
<P>
Encrypted data.
<P>
<B>Ciphertext0 </B>
<P>
The first of the two ciphertexts to be attacked.
<P>
<B>Ciphertext1 </B>
<P>
The second of the two ciphertexts to be attacked.
<P>
_________________
<P>
<SMALL>Pre-ANSI C can be supported if required. Any GUI code will probably
be written in C++ .</SMALL>
<P>
<HR>
<P>
<I>2-11</I>
<P>
<B>CiphertextSelector </B>
<P>
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.
<P>
<B>DES </B>
<P>
The Data Encryption Standard.
<P>
<B>ExtraXOR </B>
<P>
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.
<P>
<B>Host computer </B>
<P>
The computer that controls the DES search array.
<P>
<B>KeyCounter </B>
<P>
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.
<P>
<B>Plaintext </B>
<P>
Unencrypted data corresponding to a ciphertext.
<P>
<B>PlaintextByteMask </B>
<P>
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.
<P>
<B>PlaintextVector </B>
<P>
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.
<P>
<B>PlaintextXorMask </B>
<P>
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).
<P>
<B>SearchActive </B>
<P>
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.
<P>
<B>SearchInfo </B>
<P>
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
<P>
<HR>
<P>
<I>2-12</I>
<P>
board have halted.
<P>
<B>UseCBC </B>
<P>
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).
<P>
</BODY></HTML>
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed