# Should DES be avoided when developing new systems?

According to wikipedia…

DES is now considered to be insecure for many applications

However, since it can be broken relatively easy, should it not just be avoided for all applications?

-
Conclusion from the answers: Use DES if you want your encryption to be broken :-) (But maybe a Caesar chiffre would be even more effective for this goal.) – Paŭlo Ebermann Jul 21 '11 at 13:10
Presumably the reason Wikipedia says "for many applications" is that in some cases the value of the data is so very low (e.g. your shopping list) that nobody in their right mind would build/rent custom hardware to crack it. With fast modern hardware though there's not much reason to use DES as opposed to selecting a more effective and conservative solution. – D Coetzee Jul 16 '12 at 0:13

## 4 Answers

Yes. DES is no longer considered an approved algorithm by NIST, and breaking a 56-bit key can be done quickly - in 1998 the EFF DES Cracker managed to break a DES key in 56 hours. The average time it required to break any DES key was 4½ days. You could use triple DES instead, which is still considered secure, but it's very slow (in software, even single DES is slower than AES), and a time-memory tradeoff described by Martin Hellman in 1980 shows how to break 3DES with a 168 bit key in $2^{112}$ time. In addition the 64 bit block size is a major practical problem if using 3DES in some modes, as described by Thomas in his answer.

-
The link for Martin Hellman's paper has broken. Here is the first alternative I found. – cremefraiche Feb 28 at 5:06

"Considered insecure" does not mean "easily broken". Note that there is a terminology issue: there is a thing called "Triple-DES" or "3DES" which is, as far as the standard (FIPS 46-3) was putting it (until it was withdrawn), just a kind of DES.

The original DES, with its 56-bit key (namely 64 bits with 8 bits ignored), can be broken with not-so-expensive hardware -- but that's still beyond what someone can do with a single PC in a few weeks. 3DES has an effective 168-bit key, and although there is a theoretical attack with CPU cost $2^{112}$ (and space $2^{59}$ bytes), 3DES is still, in practice, quite robust.

The main security defect of 3DES is that it uses 64-bit blocks, which is a bit short; with usual encryption modes such as CBC or CTR, you could run into trouble after about $2^{32}$ blocks, i.e. 32 gigabytes -- which is not that huge with regards to current technology.

The main practical defect of 3DES is that it is darn slow in software.

So you should not use 3DES in new applications, unless mandated by an unavoidable backward compatibility requirement. AES has been designed to be better, both for security and performance, and has been heavily scrutinized for a dozen years now, so AES is the recommended block cipher. There is no need to hurry towards patching existing applications which use 3DES, though.

(For that matter, 3DES is less a worry than SHA-1.)

-
Correct me if I'm wrong, but I thought 3DES wasn't a "kind of" DES, but it was a separate algorithm called TDEA which implemented DES in itself. Which, if true, renders DES "easily broken", but not TDEA of course. – uygar.raf Jul 13 '11 at 21:08
@uygar.raf: strictly speaking, these algorithms are defined by FIPS 46-3, which is called "Data Encryption Standard", or "DES" for short. DES defines two algorithms, called "DEA" (Data Encryption Algorithm) and "TDEA" (Triple-DEA), the latter consisting of three cascaded instances of DEA. So DES designates both DEA and TDEA. But there are also other "traditional" conventions, where DES is DEA only, and TDEA is called 3DES. Or DESede. Or sometimes "DES with a 168-bit key". There is a terminology issue. – Thomas Pornin Jul 13 '11 at 21:27
Thanks for correction. Should get back reading. – uygar.raf Jul 13 '11 at 21:56
It might be worth distinguishing between CBC and CTR in terms of the problems that are encountered with an n bit cipher. As I understand it, after 2**(n/2) CBC blocks, one can expect to start extracting information about the plaintext, whereas with CTR the only change is that you can distinguish the keystream from a uniform random string, because you would expect to see a collision after 2**(n/2) blocks, but wouldn't with CTR. Obviously the best solution regardless is to use a cipher with a larger block, but I do think these are very different failure modes. – Jack Lloyd Jul 21 '11 at 12:42
@Jack: on the other hand, if one wants to encrypt several messages with a given key, each with its own random IV, things change a bit. Ultimately, with 2^(n/2) one-block messages, in CTR mode, you begin to have collisions, turning encryption into the infamous two-times pad; while CBC is not made especially worse in that situation. Hence the generic recommendation of not approaching the 2^(n/2) barrier for any mode, even CTR. – Thomas Pornin Jul 21 '11 at 12:49

Yes, DES is considered too weak to use.

NIST publishes recommendations of what encryption schemes are "allowed". Civilian government agencies, and most companies, follow NIST guidelines for security. NIST Pub 800-131A has the list of approved encryption and hashing standards.

Only 3-key "triple DES" is still considered acceptable (see page 3 of 800-131A).

-

Yes. See the other answers, but also note the risk issue. straight 56-bit DES is relatively easy to crack now, so the probability of a crack is greater; the marginal cost of using stronger encryptions, in hardware and computation, is near zero. Thus we can conclude with some rigor that DES is no longer a good choice.

-