Talk:Data Encryption Standard

Request for external link addition

• I would like to make a formal request to add http://www.celtickane.com/programming/ to the external links section of this page. It is my own website, so I wouldn't like to add it myself, but I would prefer that someone else review the website, and make the decision to add it. It contains a basic example of DES encryption in C++, which would be useful for someone who is wanting to program a DES encryptor. --Sugarskane 04:00, 20 July 2006 (UTC)

• Hi, you already did add the link yourself [1] but I think this article should not be a link farm for implementations, since there are dozens to choose from. We do link to Helger Lipmaa's portal-like page about DES [2], which itself links to quite a few DES implementations. You might contact Helger and ask him to add your implementation to his list.

  In general, please take a look at WP:EL, particularly WP:EL#Links_normally_to_be_avoided item 3, since I see you've added your links to quite a few other Wikipedia articles, which could be considered spamming. Phr (talk) 06:11, 20 July 2006 (UTC)

Any of the articles I've added have been removed -- which is why I'm adding a request to the talk page instead. I will contact Helger -- thank you. --Sugarskane 14:27, 20 July 2006 (UTC)

While your computing related articles are well-written, I don't think they are unique or notable enough to merit inclusion on any of the pages that you've added them to. There are thousands of similar articles out there. While you may be able to find examples of programming-related links on Wikipedia that are non-notable, it just means that someone hasn't cleaned them up yet. Because techies rely on the web for quick info on programming topics, programming articles are hot targets for people looking for Google Adword revenue. On one Yahoo! group that I subscribe to, a user kept posting a link J2EE tutorial that he argued was relevant. A little research revealed that he'd simply cut-and-pasted the content from Sun Microsystems's site and threw it up on his site. I realize your material is original, but as I said, I don't think it's particularly notable or unique. OhNoitsJamie ^Talk 15:20, 20 July 2006 (UTC)

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)

==

There should some discussion and a link pointing out the remarkable simple method, developed at Princeton, of pulling the crypto key out of memory. They merely spray the RAM chips with an upside down can of Dust Off to delay the decay of latent data, then insert a USB key with their extractor program, and boom! they have the keys.

http://news.cnet.com/8301-13578_3-9876060-38.html —Preceding unsigned comment added by 64.134.22.157 (talk) 22:36, 11 March 2010 (UTC)

That method has nothing to do with the DES algorithm - it would apply to any memory contents, regardless of whether the memory was a crypto key, or the algorithm that the key was used for. Hence it does not belong in an article about DES. Mitch Ames (talk) 09:18, 12 March 2010 (UTC)

Cold boot attack describes the general attack - without mentioning that the latency can be extended by cooling the chips. (Cold boot in this case refers to the power cycle, not the temperature.) Mitch Ames (talk) 09:23, 12 March 2010 (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)

Also, why did the NSA send back modified S-Boxes if the technique of differential cryptanalysis was already known to IBM? --80.132.223.175 00:49, 13 February 2006 (UTC)

NSA might probably had greater expertise in DC than IBM, or at least thought they had. Another reason, suggested by Schneier, is that the NSA needed to make sure there was no IBM backdoor in the cipher. --Townmouse 02:45, 2 September 2007 (UTC)

NSA's side of the story has been added to the article - according to a document they released in Dec 2009, they opted for 48 bits, whereas IBM suggested 64 bits. In the end NSA and IBM compromised on 56 bit key. Sounds plausible, though Whitfield Diffie notes that the document is part of Tom Johnson's NSA history from 1998, which (since it was published 25 years after the fact) deprives it of a good bit of authenticity. --Enemenemu (talk) 18:58, 14 January 2010 (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)

I am glad someone caught this. An ex-NSA man once told me that a cipher is considered "secure" as long as there is not an attack _other_ than a brute force. I believe this line, "DES is now considered insecure because a brute force attack is possible...", should be changed to "DES is now considered insecure because improved attacks over the efficiency of a brute force are possible." Sorry for my anonymitity, I just did not bother to make an account for something this small. crysys -at- gmail.com

Re that last point: that's the test of whether a cipher is well constructed. It's a necessary but not sufficient condition for being secure. The other part of the requirement is that brute-force attack has to be sufficiently hard. (Definition of "sufficiently" is something like "not economically feasible for very well funded attackers, over the useful life of the data to be protected, with a decent margin of safety".) DES has clearly failed that test for some time. (In fact, Diffie and Hellman credibly argued that it failed that test from Day One.) As for how to describe it, I see absolutely nothing wrong with "practical" -- it takes a modest investment in hardware to build a machine that can do it in a few days. Paul Koning 19:41, 6 July 2007 (UTC)

Biham, Shamir & DES

Matt C: I agree that Biham and Shamir attacked full-round DES later, but it's significant that they rediscovered differential cryptanalysis earlier. If DC was one of IBM's factors in the DES design, it seems fitting to include when it was first "publicly" discovered. Mmernex 14:23, 16 May 2007 (UTC)

Oh, absolutely—it was just that we needed to be accurate about what happened in 1990 and 1992. Having both dates is ideal. — Matt Crypto 18:10, 16 May 2007 (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.

While your "many tests on security and cryto" do sound impressive, I'm afraid your argument is not particularly convincing. We do already say that "Like other block ciphers, DES must be used in a mode of operation if applied to a message longer than 64 bits. FIPS-81 specifies several modes for use with DES, including one for authentication [2]. Further comments on the usage of DES are contained in FIPS-74". Now, I would be very happy to see additional specific details about DES and modes (such as what modes are specified in the FIPS publications and so forth), but to go into detail about basic general principles of block cipher usage is overkill in this article. Moreover, I'm afraid your explanation is confusing and incorrect in parts, particularly the ECB paragraph, which confuses the action of the mode with the operation of the DES primitive itself. — Matt Crypto 02:22, 30 October 2005 (UTC)

If the discussion is confusing, you can correct it (if you can). However, I have three textbooks in front of me and about 15 years of operational experience with DES and the discussion matches. Are you the "bully of crypto" ? I think so. All textbooks I have discuss the modes of DES in the DES discussion and do not discuss the modes in other block cipher chapters. I guess you are just going to bully your way, is that right? There is only your opinion and all the textbooks are wrong too?

*Sigh* I'll come back to this tomorrow, if I have time. It's discouraging that you've stopped presenting any arguments and started with comments about "bullying" and boasting about how experienced you are with DES and how many textbooks you have. Good, but make use of your experience and read your textbooks. You've quite clearly not explained the ECB mode correctly at all, confusingly adding a fudged explanation of the main DES algorithm itself. You wrote that, "ECB is applied to 64-bit blocks of plaintext to provide 64-bits of ciphertext. The 64-bit input vector is divided into two 32-bit blocks called the Right Block and the Left Block, and then recopied to form two 48-bit blocks. Each of these two 48-bit blocks are XORed with a 48-bit encryption key. Because ECB does not use chaining, patterns in the ciphertext can be detected; hence, ECB is not used to encrypt large blocks of data. — Matt Crypto 02:44, 30 October 2005 (UTC)

Matt is right, these explanations are totally inappropriate and are redundant for this article. You have ceased addressing his point and have started engaging in some kind of strange book-based pissing contest. I'm just going to remove them and keep them out, I'm assuming everyone else will revert along with me, there's no point in wasting energy arguing this further. Nathan J. Yoder 17:34, 1 November 2005 (UTC)

Disambig

Please see Talk:DES for a discussion related to this article. Peyna 16:16, 3 December 2005 (UTC)

NSA speculation

There is some discussion over on usenet:sci.crypt over whether to remove the speculation about the NSA. Some of it is unsourced and probably false.

I removed these two sentences:

Off the record, NSA has characterized DES as one of their biggest mistakes. If they knew the details would be released so that people could write software, they would never have agreed to it.

These are just improbable rumors, and there is no source in the NSA or even anyone who claims to have talked to anyone in the NSA about the matter. There is no date for the NSA opinion. It is unclear what the mistake was or who made the mistake. There is circumstantial evidence that NSA did not consider DES to be a mistake, although different opinions may exist in the NSA. DES was a National Bureau of Standards project, so the NSA probably did know that the details would be released.

There is a lot of wacky speculation about the NSA on the internet. This article should stick to verifiable facts. Roger 17:11, 14 July 2006 (UTC)

I originally added those sentences a couple of years ago, but I agree with you. Of course, Wikipedia articles can and should report on significant rumours, and there's been a lot of published material speculating about the nature of the NSA's involvement in the design of DES. I think the article is OK at present, although it could do with citing sources for the quotes. — Matt Crypto 20:00, 31 July 2006 (UTC)

I see you asked for a citation on the rumors about why NSA wanted DES to have a 56-bit key. I think that it is true that "it was widely believed that NSA's decision was motivated by the possibility that they would be able to brute force attack a 56 bit key several years before the rest of the world". But it should probably be noted that NSA seemed to know the true strength of DES better than anyone else, and NSA may have simply thought that the key length should match the true strength.

Inline references

I left a note asking Cyde to run his conversion bot to turn the inline references to footnotes. I hope no one minds. All featured articles are supposed to use footnotes now, I think. Phr (talk) 08:12, 14 July 2006 (UTC)

I converted 4 inline references into unformatted URL footnotes today. The article is 100% footnotes although there's room for format improvements. – Conrad T. Pino (talk) 03:07, 11 April 2008 (UTC)

Applications

Where was DES used and where is it used now? In mobile phones, pay per view, police radios?

Velle 10:45, 22 August 2006 (UTC)

When was NSA able to brute force attack the system?

In "History of DES - NSA's involvement in the design" it says

It was widely believed that NSA's decision was motivated by the possibility that they would be able to brute force attack a 56 bit key several years before the rest of the world would[citation needed].

And in "Security and Cryptanalysis - Brute force attack" it says

(...) this is often taken as an indication that the NSA possessed enough computer power to break keys of this length even in the mid-1970s.

The last one does not say much, except that some people take it as an "indication".

However, I read that some organizations brute forced it in 1999, but I have no notion of the computer power in the NSA, was it realistic for them to break it in the 70's and how difficult is it for them now?

Velle 11:03, 22 August 2006 (UTC)

I doubt the NSA could break it in the '70s. It would have taken massive computing power, and it would have been easier to put in a trapdoor. Today, however, it would be easy for them to break it. mrholybrain's talk 02:06, 9 May 2007 (UTC)

There's a good discussion on the subject in the EFF book "Cracking DES". I don't expect to see an answer to the original question ("when did NSA do this") because those projects would have been classified. But highly regarded experts Diffie and Hellman argued that NSA had the capability at the time DES was adopted. Note that "would have taken massive computing power" is a red herring. You don't do this with massive computers, you do it with custom chips, which are extremely simple, much faster, and much cheaper. The EFF engine cost only about $250,000, and only about 60% of that was for the hardware. Diffie and Hellman estimated $10,000,000 in 1976. If you apply Moore's law, that was a little off (it predicts EFF-like costs about 5 years earlier than EFF did the work) but not much; clearly NSA could have done the work, both technically and financially, within a few years after DES was adopted.

By the way, I thought about putting the Diffie/Hellman paper as a citation on that quote about NSA but didn't because it doesn't support the "widely believed" part. It does however support "was argued from the start" so maybe it'll go on with that change in wording. Paul Koning 10:52, 9 May 2007 (UTC)

Comparing DES with Rijndael Algorithm

DES uses 64 bit blocks with 56 bit key whereas Rijndael Algorithm uses 128 bit block with 128 or 192 or 256 keys

DES uses 16 rounds whereas Rijndael uses 10 rounds

While comparing the performance, Rijndael is better than DES in terms of speed, Complexity of operation and security —Preceding unsigned comment added by 220.227.28.18 (talk • contribs)

SDES

Hey ppl the Simplified Data encryption standard page does not exist. Can some one create it please? Weedrat 06:45, 22 May 2007 (UTC)

Why? It doesn't seem to be worth describing. Paul Koning 19:35, 6 July 2007 (UTC)

So far, I agree with Paul Koning that the information we have on SDES so far doesn't warrant a dedicated Wikipedia page on that topic.

Dear Weedrat, I see enough references to SDES that I agree Wikipedia should at least mention it -- so I added a few words and references at Data Encryption Standard#Simplified DES.

Is there anything else Wikipedia should say about SDES?

Perhaps that section will someday grow big enough to WP: SPLIT into a dedicated page about SDES.

--DavidCary (talk) 09:04, 20 December 2015 (UTC)

Open source software implementations?

What do you think about a section or link(s) to open source software implementations? Daniel.Cardenas 17:35, 16 June 2007 (UTC)

Perhaps, but one concern is that there's been lots of crypto pages (MD5, SHA, AES etc) that have been spammed full of links to gazillions of implementations, with the result that people are a bit reluctant to include links to any at all. — Matt Crypto 18:26, 16 June 2007 (UTC)

Biham key-collision attack

I just read a paper by E. Biham regarding his key-collision attack. (Information Processing Letters 84 (2002) 117-124) Titled: "How to decrypt or even substitute DES-encrypted messages in 2^28 steps" I don't see mention of this in the article, other than passages discounting linear and diff. cryptanalyis as "impractical" (an arbitrary quantifier). Biham's latest method described requires 2^28 known blocks, which is not completely impractical, only marginally.. my point being I'd like to add mention of this somewhere.--Raidfibre 18:17, 6 July 2007 (UTC)

Blast it!

What sort of a "Featured Articel" is this!? An (admittedly) minor pastel shaded box, but worse, "citation needed"'s in many places, and more so, some unattributed direct quotations from people! 68.39.174.238 03:19, 31 August 2007 (UTC)

Wikipedia had very lenient citation/attribution requirements back when this was featured; the article has changed little since. -- intgr ^#%@! 07:03, 31 August 2007 (UTC)

Blast it? -- What, like, with a Directed-energy weapon? ;-) Yeah, as Intgr points out, Wikipedia's standards have changed over the last 3 years, and it's a good thing that people expect the highest standards from Featured Articles. It shouldn't be too much work to bring this article in line with modern referencing requirements, at least. — Matt Crypto 08:08, 31 August 2007 (UTC)

I know that, but such articels would usually be found out and delisted under the new regime, EG MKULTRA got delisted a while ago for those reasons. 68.39.174.238 14:17, 2 September 2007 (UTC)

Confusion / Diffusion

80.230.111.1 13:09, 5 November 2007 (UTC) Eliezer Dor

The article states that

" ... the substitution ... S-boxes and the permutation .. from P box and the E-expansion provides so-called "confusion and diffusion" respectively "

I suggest removing the word "respectively".

While it is true that S-boxes (and substitutions in general) provice confusion, it is not true that transposition by itslf provides diffusion. Rather the S-box function provides diffusion within the limited scope of its action, while the transpositions (permutations and selections) help expand the scope of this diffusion to the full state.

DES and internet banks

When I am logging in to my internet bank they give me a code (over the internet) that I write into a separate device that gives back an encrypted message that I write back to the bank to log in. Now the device (which I checked uses DES) only uses 10 decimal digits (33 bits) so even if DES uses 56 bits 23 of them must in this case always be the same. Does this affect the security in some way? I do not know whether the remaing 23 bits are unique for every device (customer) or if all share the same.Agge1000 23:12, 13 November 2007 (UTC)

First, note that Wikipedia talk pages should be used for discussing improvements to articles.

But this is actually an interesting question; First of all, the key is almost certainly still a whole 56 bits; what you see on the screen is not really the key—it's the current time of day encrypted with the device's secret key; in other words, it's 10 digits of the 64-bit ciphertext output. Truncating the ciphertext does not weaken the security of DES; in fact it actually strengthens it, because the attacker has to collect at least 56 bits worth of output to avoid colliding (false positive) keys.

Technically, assuming that an attacker can predict the plaintext (which is generally the time of day), this kind of device would be vulnerable to the short 56-bit key size of DES; to pull it off, the attacker needs several outputs from the device along with their time. I can see two scenarios where this would be possible:

1. The bank teller who sells you the device could grab a few samples from every device they hand out; to make use of this information, they also need to know your log-in identifier—I'm not sure if tellers have a way to figure this out. In my bank at least, this is a random-looking 6-digit number, but other banks might use more predictable logins.

2. The attacker manages to bypass the SSL encryption from your computer to the bank. They could run a phishing site, or they could run a keylogger on your computer.

The attack is more complex than a normal brute force attack, because the attacker has to consider possible time drift, and has to match two or more truncated ciphertext blocks instead of a single full one. Other than that, I can't see why it wouldn't work. -- intgr [talk] 23:55, 14 November 2007 (UTC)

External link suggestion

Hi, I’d like to suggest newly created webpage ([3]) which comprises a presentation and an encoding application. The first one is a step-by-step presentation of DES scheme. The latter is a fully functional application which encrypts and decrypts messages of any size.

At the beginning of the presentation users can fill in appropriate form fields (Message field and Key field) but to their convenience it’s not necessary – exemplary data is provided. The presentation is divided to stages which perfectly reflect structure of the process. First of all sixteen 48-bit long subkeys are created from the given key. This part is called Key Schedule and is composed of few stages. Next, the actual encryption/decryption process ensues. Interface of the presentation is constructed in the way, which makes possible familiarizing readers with principles and output results of every step of the DES algorithm and after that moving on to the subsequent stage.

Besides above-mentioned presentation everyone can try out another utility. It is an application which encodes and decodes messages of any size, in theory of course, because server capabilities are limited. In this case size of given message can’t exceed 5000 characters. I’ve found over the Internet few DES encrypting programs, but none of them works properly. Few of them operate solely with English alphabet. Another few force users to provide data of a specific size only. Our application is devoid of those constraints. Thus, any person can use it for private, or not, purposes to encrypt and decrypt messages of any size and in any language. —Preceding unsigned comment added by Lukasz Tlomak (talk • contribs) 15:24, 13 March 2008 (UTC)

Criteria for building S-Boxes

This link says that some criteria for designing S-Boxes come from a paper by Coppersmith, but Douglas Stinson's Cryptography theory and practice talks about a 1976 speech or document by the NSA or NIST (actually the reference to NIST is a footnote in the French translation). I don't know whether these data are in the sources listed in the article. I think it's important information which should be added (if we have a reliable source). Apokrif (talk) 04:07, 2 June 2008 (UTC)

Minor Cryptanalytic Properties

DES exhibits the complementation property, namely that

$E_{K}(P)=C\Leftrightarrow E_{\overline {K}}({\overline {P}})={\overline {C}}$

where ${\overline {x}}$ is the bitwise complement of $x.$ $E_{K}$ denotes encryption with key $K.$ $P$ and $C$ denote plaintext and ciphertext blocks respectively. The complementation property means that the work for a brute force attack could be reduced by a factor of 2 (or a single bit) under a chosen-plaintext assumption.

Is this true? If I have some known plaintext M and I give it to an external system and receive the crypted text C how does it reduce my search space to know that DESk^(M^) = C^? I can see how it would reduce the search space if we did not know M or k. But considering we do know M we must still check all k (whether we check this by inverting everything or not it does not matter). 129.78.64.100 (talk) 05:13, 4 June 2010 (UTC) Ben

Presumably because the inversion takes negligible time compared to the computation of DES_k(P)? When the number of DES computations is cut in half, the total work is effectively reduced by a factor of two (I would think). decltype (talk) 06:57, 4 June 2010 (UTC)

Reductions in linear cryptanalysis data complexity under the chosen-plaintext assumption

The article currently states that

"under a chosen-plaintext assumption, the data complexity can be reduced by a factor of four (Knudsen and Mathiassen, 2000)."

In the paper in question ("A Chosen-Plaintext Linear Attack on DES"), Knudsen and Matthiassen describe Matsui's attack as needing 2^44 known plaintexts, compared to the 2^42 chosen plaintexts of their attack. However, in "The First Experimental Cryptanalysis of the Data Encryption Standard", Matsui states that the attack needs 2^43 known plaintexts. (Matsui also refers to the attack as having an 85% success rate, as opposed to the 78% mentioned by Knudsen and Matthiassen.)

Unless K+M are implicitly claiming Matsui's calculations for the probability of success with 2^x known plaintexts were wrong, I don't see how the article can claim more than a twofold improvement in data complexity through the use of chosen plaintexts.144.32.126.12 (talk) 22:06, 5 January 2011 (UTC)

I've examined "A Chosen-Plaintext Linear Attack on DES" again. The fourfold decrease in data complexity occurs when key ranking is not being used; however the paper does not contain a comparison of the data complexity of the chosen and known plaintext attacks when key ranking is being used.

I'm currently planning to come back in a few days and delete the "data complexity can be reduced by a factor of four" sentence from the article; I would do it now but I want to see if anyone raises any objections.144.32.170.32 (talk) 18:15, 12 July 2011 (UTC)

Final switch?

In the image DES-main-network.png it shows that in the last stage (the output from the F-networks) remain of the "left" and "right" after passing through the F-network. In the version I wrote the last bug I detected was recombining the output in the same order, although it seems that it has to be switched (the left hand side makes up the last 32 bits and the right hand side makes up the first 32 bits) should there be a final cross over shown at the bottom of the image? Here's the part of my code that I'm talking about:

//Split input into two halves
            bool[] left = new bool[32];
            bool[] right = new bool[32];
            for (int i = 0; i < 32; i++) {
                left[i] = data[i];
                right[i] = data[i + 32];
            }

            //Pass though F-function
            bool[] f;

            //Round 1
            f = Feistel(right, subKeys[0].Key);
            left = Functions.XOR(left, f);

            //ETC
            
            //Round 16
            f = Feistel(left, subKeys[15].Key);
            right = Functions.XOR(f, right);

            //Recombine left and right
            bool[] result = new bool[64];
            for (int i = 0; i < 32; i++) {
                result[i] = right[i];
                result[i + 32] = left[i];
            }

--Simpsons contributor (talk) 18:29, 1 July 2011 (UTC)

I've just remembered to respond to this (sorry it took half a year) but after an even number of rounds the original "left" if on the "right" and so that is the apparent flip. It was the copying to the final array thaw was confusing things. --Simpsons contributor (talk) 03:26, 22 December 2011 (UTC)

is the Figure 1 correct ? I think that the final swapping is missed (before the FP)

Hello, In the chapter 2.1 (Overall structure), at the third paragraph, we can see "After the final round, the halves are swapped;". But on the "Figure 1", I don't see this last swapping.

I am not very good in crypto, I came on this page to learn, so may be I didn't understand very well.

Thanks for who will analyse that :)

Bye — Preceding unsigned comment added by 93.20.247.38 (talk) 11:51, 5 October 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on Data Encryption Standard. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20140226205104/http://origin-www.computer.org/csdl/mags/co/1977/06/01646525.pdf to http://origin-www.computer.org/csdl/mags/co/1977/06/01646525.pdf
• Added archive https://web.archive.org/web/20130918020036/http://www.nsa.gov/public_info/_files/cryptologic_histories/cold_war_iii.pdf to http://www.nsa.gov/public_info/_files/cryptologic_histories/cold_war_iii.pdf
• Added archive https://web.archive.org/web/20090527065754/http://crypto.junod.info/sac01.html to http://crypto.junod.info/sac01.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 07:39, 7 December 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Data Encryption Standard. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20080625202735/http://csrc.nist.gov/publications/fips/05-9945-DES-Withdrawl.pdf to http://csrc.nist.gov/publications/fips/05-9945-DES-Withdrawl.pdf
• Added archive https://web.archive.org/web/20070615132907/http://www.research.ibm.com/journal/rd/383/coppersmith.pdf to http://www.esat.kuleuven.ac.be/~abiryuko/mla.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:15, 20 May 2017 (UTC)

Unverifiable Source for NSA's role in DES?

The section that talks about the NSA's role in modifying DES uses this essay for its source, but the essay cites no sources and the link to where the essay was originally found is dead. Are there any verifiable sources for the claims about NSA involvement that this source covers? — Preceding unsigned comment added by 139.62.13.235 (talk) 14:40, 18 September 2018 (UTC)

Misattributed citation?

From the aricle:

NSA worked closely with IBM to strengthen the algorithm against all except brute-force attacks and to strengthen substitution tables, called S-boxes. Conversely, NSA tried to convince IBM to reduce the length of the key from 64 to 48 bits. Ultimately they compromised on a 56-bit key.

Note that the two citations are visually identical but reference different URLs. I was not able to find the quoted passage in either of the linked documents. I don't understand what the "differently redacted" comment is supposed to mean here, in any case, I don't find the quote to be substantiated. 138.246.3.123 (talk) 14:43, 1 July 2022 (UTC)

References