Talk:Data Encryption Standard

Hardware speeds

I snipped this for now; chips that run at several Mb/s are no longer particularly impressive, crypto-wise, even for Triple DES.

The DES algorithm lends itself to integrated circuit implementation. By 1984 the Bureau of Standards had certified over 35 LSI- and VLSI-chip implementations of the DES, most on single 40-pin chips, some of which operate at speeds of several million bits per second.

— Matt 13:27, 14 Jul 2004 (UTC)

Matt, The certification program is itself significant if rather ineffectual given Moore's Law.

Sure, I'll try and work in a mention of the certification program; giving details of specs is probably a bit redundant now, though, I'm guessing. — Matt 19:52, 14 Jul 2004 (UTC)

On another point, I seem to recall that Feistel was not a formal member of the team led by Tuchman. Consulting from another project and all... This from my memory of an account by Tuchman.

I took at least some of the names from a list given by Coppersmith (the "Coppersmith, 1994" reference) as people who'd been on the team developing crypto at IBM; I tried to word it to avoid any suggestion that it was the "DES design team", as, as you point out, it's not really clear whether, e.g. Feistel, was part. — Matt 19:52, 14 Jul 2004 (UTC)

Great work on this, by the way. I think the infobox is a great idea for presenting the 'executive summary' information. Very nice. The chronology is superb also. But I predict there will be sniping from those parsimonious of words in articles. I've only a few wording nits that I'll get around to sometime. ww 19:02, 14 Jul 2004 (UTC)

Thanks, glad you like it; can you think of any other "data field" that might be worth including on the InfoBox? Also, where do you think it might get too wordy? — Matt 19:52, 14 Jul 2004 (UTC)

Matt, I'm not likely to be one of those complaining of too many words; I'm nearly alwasy on the other end of such tussles. As for the infobox, the one thing that strikes me as worth adding (at least now) is an evaluation of status. Not merely such and such an attack has progressed thus and so far, but whether that attack makes the algorithm insecure against that attack and so insecure. One thing Joe User will find useful (even if the details escape) is that evaluation -- if I see this algorithm being claimed to be swell in some ad, I shouldn't take it seriously as the algorithm has been broken. ww 18:58, 19 Jul 2004 (UTC)

Why 56 bits

I just added a note making it a bit more explicit why 56 bits was an appropriate choice of key length, and not an attempt by the NSA to weaken the cipher. I'm a bit surprised all the material about differential cryptanalysis made it in without anyone explaining that it disproved the conspiracy theories. Metamatic 14:42, 21 Aug 2004 (UTC)

Your note was:

In fact, 56 bits was exactly the minimum length of key required to ensure that cracking the key by brute force would always be tougher than using differential cryptanalysis. In other words, the NSA had made the key as long as it needed to be in order not to be the weakest link, but no longer.

Hmm...well, I misread this at first, but it's not quite accurate: 1) The 56-bit key length did indeed prove to be the weakest link in the encryption. A brute force attack on the key remains the only practical way of breaking DES. 2) Out of the two original worries (S-box tampering and key-length shortening), there is evidence for vindicating the NSA on the S-box front, but it's still widely believed that they interfered with they key size. "NSA convinced IBM that a reduced key size was sufficient", and all that. 3) You're saying that the NSA chose 56 bits in order to make brute force search more expensive than differential cryptanalysis (complexity around about 2⁴⁷)? Despite being a strange design strategy (DC is a certificational weakness), do you have evidence that this was NSA's reasoning? — Matt 08:58, 22 Aug 2004 (UTC)

table

you can get rid of all those smalls with a style="font-size:85%" or something, can't you? - Omegatron 01:04, Mar 16, 2005 (UTC)

Yes, you can, thanks for the tip! — Matt Crypto 12:38, 16 Mar 2005 (UTC)

Brute Force

Hi. A nicely written page. This might sound a bit pedantic but could I question the wording of "DES is now considered insecure because a brute force attack is possible..."

As I understand it a brute force attack is always possible on virtually all encryption algorithms (exception of one time key pads) merely that with a useable algorithm it is not practical within the useful timelife of the data. Thus 56-bit DES became unuseful because it is now crackable whilst the data is still sensitive.

Any thoughts? --Grapeswrath 03:00, 20 September 2005 (UTC)

Yeah, I don't mind replacing "possible". I'm unsure about an unqualified "practical", though, because it's still quite an effort to do brute force over 56 bits, even in 2005. — Matt Crypto 11:36, 20 September 2005 (UTC)

How about something like "feasible with todays hardware". bit wordy....--Grapeswrath 12:54, 20 September 2005 (UTC)

Or just "possible within 24 hours"....--Grapeswrath 13:11, 20 September 2005 (UTC)

Should include DES modes

DES modes are important. Not going to accept casual deletions from Matt Crypto.

Think of it this way: should we include a section on modes of operation in each and every article on a block cipher? Clearly not. The sensible solution is deal with it in a separate page. — Matt Crypto 01:20, 30 October 2005 (UTC)

Think of this this way, you don't have to give a detailed discussion, but the modes should be mentioned and referenced in detail in another page. The level of discussion I added is appropriate. Reference the other page for details. BTW: I'm not a fan for debating memes like "clearly not" (clearly your opinion) as that is normally a way people tend to short circuit discussions. It it was clear, I would not have added critical info :-) When I read this page, the first thing that jumped out was - oh! what a pedantic discussion with no operational context - must of been by PhD or MS level students who don't actually implement cryto in the real world in network or data protocols. DES was made to actually do work, not to just be debated from an academic perspective and crytoanalysis view. Hence, I found the discussion on DES, pedantic and academic, and think it needs a bit of actually operational knowledge. The 3DES discussion is fully of errors, BTW, and the modes were not even described correctly and the representation of the modes were inaccurate.

You haven't really answered the question. Would you have us include a section on all the modes in each and every block cipher article? The issue is where it is best to include a lengthy discussion on general-purpose block cipher modes. ECB, OFB, CBC, CFB and CTR modes can be used by any block cipher, not just DES. General stuff on modes is best put in the block cipher modes of operation article. If we include any information on modes here, it should be specific details concerning DES and modes that aren't more widely applicable to block ciphers in general. — Matt Crypto 02:03, 30 October 2005 (UTC)

I did not create an lengthy discussion, I created a summary one. Using your logic, one can argue that most of the details in any entry is more appropriate on another page. I have many texts on security and cryto, and all of them have discussion of DES modes in the DES chapter. Get over it. When I read the discussion as you want to revert, it is seriously lacking and it pedantic v. useful to readers who actually use DES. As far as "all block ciphers" and when to discuss modes, please ask a more specific question, not a sweeping generalization. The reason we discuss modes in DES is that all the major texts do because of the status of DES in the history of ciphers.