DESX
Designer:
Ron Rivest
Description:
If K, K1 and K2 are the subkeys encoded as described below, then encryption and decryption are defined by:
EDESX[K, K1, K2](P) = EDES[K](P XOR K1) XOR K2
DDESX[K, K1, K2](C) = DDES[K](C XOR K3) XOR K2
If the user key length is 24 bytes, the first 8 bytes represent the key K used for the DES operation, and the two subsequent blocks of 8 bytes represent the "whitening" keys K1 and K2, in that order.
If the user key length is 16 bytes, the first 8 bytes represent the key K used for the DES operation, the second 8 bytes represent the whitening key K1, and K2 is derived from K and K1 as specified in the first reference below.
References:
- [Def] Mark Riordan,
- Posting to Usenet newsgroup sci.crypt, 1 Mar 1994.
- (Message-ID: <2ku9uc$sr8@msuinfo.cl.msu.edu>)
- [An] Joe Kilian, Phillip Rogaway,
- "How to protect DES against exhaustive key search,"
- [Inf] U.S. National Institute of Standards and Technology
- NIST FIPS PUB 46-2 (supercedes FIPS PUB 46-1), "Data Encryption Standard", U.S. Department of Commerce, December 1993.
- ip46-2.htm
- "Chapter 12 Data Encryption Standard,"
- Applied Cryptography, Second Edition, John Wiley & Sons, 1996.
- [An] J. Kelsey, B. Schneier, D. Wagner,
- "Related-Key Cryptanalysis of 3-WAY, Biham-DES, CAST, DES-X, NewDES, RC2, and TEA"
- Key length:
- Block size: 8 bytes.
Comments:
- Implementations MUST ignore (i.e. not check) the parity bits of the single-DES key. KeyGenerators for DESX SHOULD generate entirely random keys (possibly avoiding DES weak keys). In the case of a 16-byte key, the input to the "hash procedure" which generates K2 is the original user key, without any adjustment to parity.
- There do not appear to be any "official" test vectors for DESX, so for reference we provide the following (the first was calculated using Mark Riordan's C implementation, and the second by hand based on official DES test data):
- key = <0123456789ABCDEF1011121314151617>
- plaintext = <4445535864657378>
- key = <01010101010101010123456789ABCDEF1011121314151617>
- plaintext = <94DBE082549A14EF>
- ciphertext = <9011121314151617>
Security comments:
- The paper "How to protect DES against exhaustive key search" proves that attacks on DESX that assume a "black-box" model for DES require a work factor of 2118. This does not take into account any possible weaknesses of DES, apart from the key complementation property. In particular, DESX is no more secure than DES against linear and differential cryptanalysis.
- DESX is vulnerable to related-key attacks, and therefore it should only be used with keys that are generated by a strong PRNG, or by a source of bits that are sufficiently uncorrelated (such as the output of a hash function).
|
