Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
The key space of DES includes some keys that are weak, which results in a ciphertext that is extra vulnerable to cryptanalysis.
Is TDEA (also known as TripleDES) invulnerable to those weak keys? Or, is it necessary to filter cryptographically-randomly generated TripleDES keys for the list of weak/semiweak keys?
A weak key for a block cipher is a key such that encryption and decryption turn out to be the same function. This means that with such a key, a black box which nominally encrypts things only can also be used to decrypt things. A semi-weak key is a key such that the decryption function with that key is identical to the encryption function with another key.
DES is a permutation with 64-bit blocks; there are 264! such permutations (it is a huge number, close to 10347382171305201285699) and the key selects one such permutation. There are "only" 256 possible keys, so the 256 encryption functions and the 256 decryption functions "should" be all distinct from each other, with an overwhelming probability, if we assume that the key selects permutations "at random" (that's the "ideal cipher" model). The existence of weak and semi-weak keys is thus some extra structure, which is worth mentioning, although calling them "weaknesses" is an overstatement. Weak keys and semi-weak keys are part of a more general class of "weaknesses" called related keys. Related keys can be a concern in some specific scenarios where an attacker can force usage of related keys through some weakness in the key generation process; unless something is done thoroughly wrong (like it was done with WEP) or the block cipher is used in an unusual way (e.g. as a building block for a hash function in a Merkle-Damgård construction), related keys attacks are no real threat to security.
Testing a given key for being "weak" is not useful with DES, because risk of a properly generated key being "weak" is extremely low. Simply "trying" a few thousand potential keys ("bruteforcing") will yield a much higher success rate for much less effort.
3DES being three DES instances in a row, it also has "weak keys": given weak keys K1, K2 and K3 for DES, the key K1 || K2 || K3 is a "weak key" for 3DES. As is the case for DES, this is a noteworthy mathematical curiosity, but it has no practical security implications.
A weak or semiweak DES key used as one of the three keys in TripleDES does not cause a weakness in TripleDES according to RFC 2451. However, there is a separate weakness in TripleDES keys that should be checked.
(TripleDES is also known as DES-EDE3. EDE stands for Encrypt-Decrypt-Encrypt.)
DES has 64 known weak keys, including so-called semi-weak keys and possibly-weak keys [Schneier95, pp 280-282]. The likelihood of picking one at random is negligible.
For DES-EDE3, there is no known need to reject weak or complementation keys. Any weakness is obviated by the use of multiple keys.
However, if the first two or last two independent 64-bit keys are equal (k1 == k2 or k2 == k3), then the 3DES operation is simply the same as DES. Implementers MUST reject keys that exhibit this property.
3DES inherits those weak keys, so this "weak key vulnerability" applies to 3DES also.
