diamond.txt

DIAMOND加密算法的原代码

The Diamond Encryption Algorithm

by Michael Paul Johnson

Abstract--Diamond is a royalty-free, symmetric key block cipher 
encryption algorithm based on a combination of nonlinear 
functions. This block cipher may be implemented in hardware or 
software. Diamond uses a block size of 128 bits and a variable 
length key. A faster variant of Diamond uses a block size of 64 
bits. Diamond is an incremental improvement over MPJ2 and MPJ.

Index Terms--Diamond, encryption, cryptography, cryptanalysis, 
computer security, communications security, MPJ, MPJ2.

INTRODUCTION

General symmetric key block ciphers have numerous applications 
in computer security, communications security, detection of data 
tampering, and creation of message digests for authentication 
purposes. The longer any one such algorithm is used, and the 
more use it gets, the greater the incentive to break it, and the 
greater the probability that methods will be devised to break 
the algorithm. For example Michael J. Wiener has shown that 
breaking DES is within the capabilities of many nations and 
corporations [1]. This sort of reduction in the relative 
security of DES was anticipated several years ago. One proposed 
solution is the International Data Encryption Algorithm (IDEATM) 
cipher [2], which was described in [3] and [4] as the Improved 
Proposed Encryption Standard (IPES). Another one is the MPJ 
Encryption Algorithm [5], which evolved to the Diamond 
Encryption Algorithm. In the field of cryptography, it is good 
to have many good algorithms available.

DESIGN OF DIAMOND

Diamond was designed to be strong enough to provide security for 
the foreseeable future. It was also designed to be easy to 
generate keys for, and to be practical to implement in hardware, 
software, or in a hybrid implementation.

Strength

Three major factors influence the strength of a block cipher: 
(1) key length, (2) block size, and (3) resistance of the 
algorithm to attacks other than brute force (such as 
differential cryptanalysis) [3] [6]. The key length is variable 
to allow you to select your own trade-off between security and 
volume of keying material needed. The block size is chosen to 
make brute force attacks using precomputed tables require an 
obviously intractable amount of data storage.

Diamond uses a variable length key of at least 40 bits. The use 
of at least a 128 bit key is recommended for long term 
protection of very sensitive data, as a hedge against the 
possibility of computing power increasing by several orders of 
magnitudes in the coming years.

The block size is fixed at 128 bits, because larger block sizes 
are unlikely to make any practical difference in security, and 
because this in a convenient binary multiple.

The problem of making sure that there is no known attack that is 
more efficient than brute force is much more difficult than 
simply selecting sizes for keys and blocks. This is attempted by 
creating a composite function of simpler nonlinear functions in 
such a way that the internal intermediate results cannot be 
solved for and such that there is a strong dependence of every 
output bit on every input bit and every key bit. An ideal 128 
bit block cipher would use a z bit key to select one of 2z 
functions from the set of all one to one and onto functions that 
map one input block of 128 bits to one output block of 128 bits. 
Ideally, these 2z functions would be the most nonlinear, 
difficult to analyze functions out of the (2128)! possible 
functions. In practice, the key selects one of 2z functions from 
an arbitrary selection of possible functions numbering between 
2z and (2128)!.

The use of purely nonlinear functions makes a large portion of 
mathematical tools ineffective for cryptanalysis.

Ease of Key Generation

Key generation should be as simple as generating a random number 
by measuring some random physical process. Since there is no 
complex or secret strong key selection process, distributed key 
management protocols are practical. Distributed key management 
is preferable in many applications to centralized key management 
because there is no single point of failure at which the whole 
system could be compromised.

Practical to Implement in Hardware or Software

The prototype algorithm is implemented in a program for a 
personal computer. When properly implemented in hardware, 
Diamond should not significantly slow down any practical digital 
data stream. On the other hand, setting up a new key need not be 
as fast as the encryption and decryption operations, since (1) 
key change operations are less frequent than encryption and 
decryption operations, and (2) a slower key setup operation 
discourages brute force attacks.

BASIS OF DESIGN

The thought process that went into the design of Diamond is 
based on the following ideas:

1. Linear functions and combinations of functions can often be 
solved analytically in ways that are not obvious to the cipher 
designer, and should be avoided. This includes standard 
arithmetic functions, math in finite fields, and Boolean 
arithmetic.

2. Reversible block ciphers with a block size of n bits can be 
viewed as a simple substitution cipher on an alphabet of 2n 
characters, with a key that selects the permutation used.

3. Simple substitution ciphers can be represented with a look-up 
table or array, but in practice the array required is too big to 
fit comfortably in a computer's memory.

4. An adequate subset of the oversized look-up table can be 
simulated by simply interleaving rounds of substitution of 
sub-blocks with bit permutations that serve to spread functional 
dependencies across sub-block boundaries.

DESCRIPTION OF ALGORITHM

The Diamond Encryption Algorithm consists of three main parts: 
(1) key scheduling, (2) substitution steps, and (3) permutation 
steps. Encryption and decryption both consist of n rounds of 
substitution operations, where n is at least 10. Each 
substitution operation takes each of the 16 input bytes of 8 
bits each, and substitutes another byte for it based on the 
contents of the substitution array for that byte position and 
round number. The key scheduling operation fills the internal 
substitution arrays based on the key. Between each substitution, 
a fixed permutation step uses a bit selection process to make 
each output byte a function of eight different input bytes. 
Unlike DES, every round alters every byte of the input block 
(instead of just half of the input block). After 5 rounds, bit 
of the output block is a nonlinear function of every byte of the 
input block and every bit of the key. The additional rounds 
after the fifth round serve to ensure that solving for the 
contents of the individual substitution arrays is more work than 
a brute force attack on the cipher. They also serve to increase 
the number of possible functional relationships that the key 
selects from, thus making this algorithm closer to the ideal 
block cipher, and making cryptanalysis more difficult.

 Key Scheduling

There is one substitution array for each of the 16 bytes of the 
encryption block for each round. For a ten round implementation 
of Diamond, 160 substitution arrays are to be filled. Each of 
the 160 arrays contains 256 elements of one byte each. It is 
convenient to look at the set of substitution arrays as one 
three dimensional array, indexed by round, byte position within 
the 16 byte encryption block, and input byte value. A similarly 
indexed inverse substitution array is used during decryption. 
For the substitution to be reversible, each of the 256 possible 
values of an 8 bit byte must occur exactly once in the array. 
The process used to make this happen consists of five processes: 
(1) array filling, (2) element placement, (3) pseudorandom key 
expansion, (4) pseudorandom number normalization, and (5) array 
inversion. Although key scheduling can be done more quickly in a 
dedicated hardware implementation, a more economical hybrid 
design would do the key scheduling in firmware and the actual 
encryption or decryption in hardware.

Array filling is simply a nested loop where all 160 substitution 
arrays are filled. It is concisely expressed in this pseudo 
code:

For rounds := 1 to n
        For byte position := 1 to 16
                For element value := 255 down to 0
                        Place this element.

Element placement is done by placing the current element in one 
of the unfilled positions in the current array. The unfilled 
positions of the current array are numbered from 0 to the value 
of the element being placed. A number in this same range is then 
selected by generating a pseudorandom number normalized to this 
much smaller range. This offset is used to place the current 
element and mark that location as having been filled. In the 
trivial case where there is only one more unfilled element, no 
pseudorandom number is generated.

Pseudorandom key expansion uses a simple method to provide key 
dependent bits as needed to place array elements. A pointer is 
set to the first 8-bit byte of the key. A 32 bit CRC accumulator 
is set to all ones (FFFFFFFF hexadecimal). This initial value is 
used rather than all zeros so that an all zero external key 
would not be weak. Every time a pseudorandom number is 
requested, the CRC is updated using the CCITT CRC-32 [7] using 
the key byte pointed to by the pointer. The pointer is then 
moved to the next key byte. After the pointer is moved beyond 
the end of the last key byte, the CRC is updated with the least 
significant byte of the size of the key (in bytes), then with 
the next to least significant byte of the size of the key (in 
bytes), then the pointer is moved back to the first byte of the 
key. If the actual key size used is not a multiple of 8 bits, 
then the unused bits of the last key byte are set to 1, with the 
used bits occupying the least significant bits of the byte.

Although no upper limit is explicitly given for key size, 
increasing the key size provides no significant increase in 
security if more than approximately 28 672