Talk:Triple DES

From Wikipedia, the free encyclopedia

Hum..; Effective keysize is 112 bits not 168. There's an attack... JidGom 09:03, 16 Dec 2003 (UTC)

Matt, I'm not sure Tuchman being one of the patentees needs to be mentioned either. On the other hand, I see no reason to decide for readers that it doesn't, though perhaps not here. In the DES article maybe. I know that I was surprised to learn it, so on entropy grounds it would appear to be loaded with information, and so worth mentioning.

ww 14:22, 28 Apr 2004 (UTC)

Yep, it would be good to have some patent information in the DES article (US patent 3,962,539); I think we have enough context on Tuchman here, though. — Matt 14:47, 28 Apr 2004 (UTC)
Matt, Agreed, then. You want to put it in there? ww 14:52, 28 Apr 2004 (UTC)

Contents

[edit] Attacks on 2DES, 2KEY-3DES & 3KEY-3DES

Rasmus, I'm not sure why your edit re-added the sentence "The use of three steps is essential to prevent meet-in-the-middle attacks; double DES would have serious vulnerabilities." This contradicts your statement in the changelog that 2 key 3DES is not vulnerable to meet-in-the-middle attacks. This statement should either be removed if your statement about meet-in-the-middle attacks is true, or moved up to the prior paragraph if it is not. I am not going to make the edit because truthfully I don't know much about these attacks. — RamanGupta -- 30 June 2005 20:12 (UTC)

I googled the meet-in-the-middle attack, and several sites do seem state that two-key triple DES is vulnerable to that type of attack -- in fact, it seems that even the security of triple DES is reduced from the same attack, but not to the same extent as two-key:
http://www.rsasecurity.com/rsalabs/node.asp?id=2231
http://searchsecurity.techtarget.com/tip/1,289483,sid14_gci968714,00.html?track=NL-102&ad=486202
http://www.everything2.com/index.pl?node_id=927656
RamanGupta 1 July 2005 06:07 (UTC)
Note the difference between double DES and 2 key triple DES. Double DES is the operation DES2(P):=DESk2(DESk1(P)), ie. two DES encryptions with two different keys. 2-key 3DES is the operation 2KEY-DES3(P):=DESk1(DES-1k2(DESk1(P))), ie. 3DES where k1=k3.
As meet-in-the-middle attack explains, double DES is only one bit more secure than single DES. This should explain the first sentence. 2KEY-3DES, however, is not vulnerable to meet-in-the-middle attacks. There are other attacks on it, but these require large amounts of known pairs of plaintext and ciphertext, so they aren't really practical.
I read your three links, and I can't see where they contradict this. The rsasecurity mentions the chosen-plaintext attack and the known-plaintext attack. Both 3KEY-3DES and 2KEY-3DES has 112-bits security, even though 3KEY-3DES has a 168 bit key. This is due to the meet-in-the-middle attack (I have clarified this in the article). But except for that, neither should be vulnerable to meet-in-the-middle attacks.
Rasmus (talk) 1 July 2005 07:36 (UTC)
Right, now I understand, sorry for the confusion. I was stupidly thinking that when people said "double DES" they were just using imprecise wording for 2-key Triple DES. That being said, in order ot make this clearer and flow better in the article I moved the discussion of the number of steps (both single and double) a paragraph up. I think it now flows better as it comes right after the discussion of the number and type of operations required for 3DES, and it smoothly flows from a discussion of 3DES, to 2DES, to single-DES compatibility.
One other thing, most articles on the subject seem to either disagree on the strength (in bits) of DESede, or they state that it is not known with certainty. Therefore, why is the article so certain that 3DES provides 112 bits of security? Should this be softened to reflect the uncertainty in the literature, or at least a source attributed to defend the factual nature of the statement?
RamanGupta 1 July 2005 20:59 (UTC)
Yes, that flows better. As for the security of 3DES, I can't really see why we should be uncertain of it. Of course we could discover an attack, but that is also true for DES, AES and lots of other algorithms that are not provable secure. In your second link ("expert advice") he claims that the security of 3KEY-3DES could be anywhere between 113 and 167 bits. But it is easy to see, that 3KEY-3DES is vulnerable to a meet-in-the-middle attack: By using 256+2112 operations and 256 storage, we can break 3KEY-3DES, so the security is at most 112+ε bits.
Rasmus (talk) 1 July 2005 23:18 (UTC)
OK, sounds good. RamanGupta 2 July 2005 23:35 (UTC)

Matt does not discusssing modes, but without it, it is very incomplete, and borderline pedantic. Without operating modes, the cipher has no purpose. --CISSP Researcher 2005-10-29T19:59:11

[edit] Non-Standard Abbreviation?

On the other hand, since there are variations of TDES which use two different keys (2TDES) and three different keys (3TDES) the non-standard abbreviation 3DES is confusing and should be avoided. Huh? I've worked extensively with various firewalls from numerous manufacturers, and I've never seen Triple DES abbreviated any other way. Anybody else have a different experience?--Roland 19:15, 29 June 2006 (UTC)

I've seen 3DES, DES3, and occasionally TDES. I've never seen 2TDES or 3TDES. Phr (talk) 05:16, 11 July 2006 (UTC)
In 5 years of working in IT, I've only seen it abbreviated '3DES', and I once heard it verbalized as Triple DES. I thought it was strange that the article said it is confusing, non-standard, and to be avoided, since it's literally the only abbreviation I've ever seen, and makes perfect sense to me. 67.53.145.42 22:44, 12 November 2007 (UTC)
The fact that a lot of people do a mistake does not mean we should not describe it as a common mistake. The official way to abbreviate `triple' is `T': the definitive source about the algorithm is `NIST Special Publication 800-67' and its full name is `Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher'. The two-key variant is officially (see, e.g., SP 800-78-1) abbreviated as `2TDEA'. GBL (talk) 12:04, 20 November 2007 (UTC)
Official or not, it's going to cause more confusion referring to it by the "official" standard. You might call it de-evolution or bastardization of the language used to describe DES, but it happens every day. Heck, Washington Mutual just officially changed their name to WaMu not because it's more descriptive or accurate, but because that's what the majority of people call it anyway. In the end it's just a word and I doubt that 99.9% of people care about what the official document says. —Preceding unsigned comment added by 67.115.118.5 (talk) 23:18, 10 April 2008 (UTC)

[edit] 2-key TDES with k2 derived by mixing k1 and k3?

Has 2-key TDES with the third key derived as a mixing function of the other two (other than the trivial k3 = k1) been studied? --Damian Yerrick (talk | stalk) 03:14, 4 October 2007 (UTC)

[edit] When was it introduced?

Our article says:

When it was found that a 56-bit key of DES is not enough to guard against brute force attacks, TDES was chosen as a simple way to enlarge the key space without a need to switch to a new algorithm.

I thought that I recalled triple DES was proposed for key encryption keys or key derivation functions in the 1970s, when single DES was still considered adequate for message encryption; however I have no reference that that was the original motive. Certainly ANSI X9.17 specified EDE triple DES for key generation in 1985, at a time when DES had just been re-certified for data encryption. It makes sense; if you used single DES for key generation, then the attacker can obtain many keys for the price of attacking just one. Thus, no matter how strong your cipher is, your key generator must logically be stronger.

We might also point out that the advantage of EDE over EEE lies principally in hardware implementations. Recalling that originally, only hardware implementations complied with the standard, a chip that implements EDE is "backwards compatible" with single DES, whereas a chip that implements EEE is a completely different cipher. (In software there is also a small advantage in that IP-1 from one round and IP from the next cancel out, thus eliminating 4 slow bit-level permutations; however this is a relatively trivial matter.) -- Securiger 05:55, 2 December 2007 (UTC)

"the advantage of EDE over EEE lies principally in hardware implementations."
I really doubt that was the primary reason why EDE was chosen. EEE is inherently vulnerable to meet-in-the-middle attacks, it would require just 258 operations and 256 blocks worth of storage. -- intgr [talk] 03:22, 3 December 2007 (UTC)
I don't think that's correct. The chosen plaintext MITM you are referring to is effective against any 2 key triple DES variant, regardless of whether it use D or E in the middle, and ineffective against 3 key versions, once again regardless of whether they were EDE or EEE. It is a reason for preferring 3 keys to 2 keys, not for preferring EEE to EDE. (Of course, other, later chosen CT attacks are effective against 3 key 3DES, but were discovered many years later, and don't get down to 256 work.) Also, I have found a reference in which backwards compatibility is specifically mentioned as the reason for preferring EDE: reference 2 from our article. -- Securiger (talk) 10:22, 28 February 2008 (UTC)

[edit] Clarification Needed, etc...

The security section (http://en.wikipedia.org/wiki/Triple_DES#Security) discusses attacks on DES and states "This is not currently practical." However "currently" is not defined. Assuming "currently" is as of when someone wrote that bit of the page do you really expect wiki users to go back in the page's history and try to find out when a particular bit was added?

Personally with the way world Governments are phasing out DES I would definitely say it is NOT secure. (For example: http://www.cse-cst.gc.ca/services/crypto-services/crypto-algorithms-e.html , states use of 2 Key Triple-DES is to be discontinued by 2010. Also note the suggestion that a key's cryptoperiod should not exceed 7 days, this strongly suggests that it can be broken easily in 8 days (or less).)

I'm also wondering why this page contains no references to the distributed.net DES challenges (http://www.distributed.net/des/) ? 206.172.0.196 (talk) 12:25, 2 May 2008 (UTC)

First of all, you're confusing DES and Triple DES -- they are different things. You can buy a DES cracker for $10,000, but 3DES will still be secure for all practical purposes for a while.
The feasibility of any certain attack does not change overnight; I think it would be rather silly to write anything more certain there. Yes, 112-bit keys are being phased out because the government wants to move on way before there is a practical attack. -- intgr [talk] 05:35, 3 May 2008 (UTC)
Ok my comment about distributed.net should have been on a higher level page. Unfortunately "currently" is still vague and contextless. 206.172.0.196 (talk) 11:39, 5 May 2008 (UTC)
The complexity of the attack by Lucks is well defined in the first sentence of the paragraph. In an academic paper it would be sufficient to just give those numbers and nothing would be vague or contextless. On Wikipedia it seems like a good idea to add that this attack is not currently feasible just to avoid any confusion. I.e. readers might otherwise wonder why NIST still considers 3-key triple DES secure despite the existence of an attack. Since 288 really is a lot of memory it would be difficult to predict how long it will take before the attack becomes practical. 85.2.105.242 (talk) 00:23, 6 May 2008 (UTC)
Here's some context: Seagate recently announced that they're the first hard drive manufacturer to sell a billion hard disks, 79 million terabytes in total. 79 million terabytes is 266 bytes, and can store "merely" 263 3DES blocks. As you can see, even this outrageous figure is orders of magnitude smaller than needed by the attack. However, I'm not sure if citing this as an example in the article would be original research or not. -- intgr [talk] 05:58, 6 May 2008 (UTC)
That's certainly a convincing argument. Though I just added NIST's recommendation so that the article contains a year as requested by the OP. My main concern however is the unreferenced billion-dollar budget comment. It is not even clear if that comment talks about the 2 or 3-key variant. 85.2.18.116 (talk) 20:03, 6 May 2008 (UTC)
Ok, Biham's attack, which is described on page 7 of his paper requires a table with 284 entries. Hence, the comment that breaking TDES with a billion dollar budget looks a little dubious. I'm therefore removing it. 85.2.18.116 (talk) 20:29, 6 May 2008 (UTC)
"On Wikipedia it seems like a good idea to add that this attack is not currently feasible just to avoid any confusion." I think you're missing my point, I'm not talking about the feasibility of the attack. I'm trying to point out that if someone comes to read this page in a year, two, five ... "currently" is vague and contextless. Unless you expect "currently" to mean 1998 when the Lucks paper was written (according to the footnote). As we're having this discussion obviously I now realize that "currently" is meant to mean "as of May 2008", this would not be obvious to other readers, especially considering the paper the statement is based upon is 10 years old. —Preceding unsigned comment added by 206.172.0.196 (talk) 15:25, 7 May 2008 (UTC)
Anyone have any further thoughts on this?
Also note the statement "NIST considers 3-key TDES to be appropriate through 2030" is not entirely correct. Based on the reference NIST doc (pg 65/141):
"Table 4 provides recommendations that may be used to select an appropriate suite of algorithms and key sizes for Federal Government unclassified applications. A minimum of eighty bits of security shall be provided until 2010. Between 2011 and 2030, a minimum of 112 bits of security shall be provided. Thereafter, at least 128 bits of security shall be provided."
It's only good "through 2030" for "Federal Government unclassified applications". 206.47.249.251 (talk) 13:20, 9 June 2008 (UTC)
NISTs resposibility are recommendations for protecting sensitive unclassified information. Classified data is rather the domain of the NSA. Hence, everything in Special Publication 800-57 applies to unclassified information only and not just the recommendations for TDES. This can be easily seen from the introduction of this document. So, what is wrong with NIST doing exactly its job? 85.2.78.78 (talk) 22:40, 9 June 2008 (UTC)
Ok I guess that's just me misunderstanding the US Gov't information classification scheme. I was thinking "unclassified" meant non-sensitive. Though according to http://en.wikipedia.org/wiki/Classified_information#United_States there are 3 "classified" levels while in a country like Canada there are 6 (3 for "Designated" information and 3 for "classified" information [classified information pertains to national interest]).Geez, what a tangled web. Anyway I'm assming you're implying that the US has not only the 3 classified levels but also some equivalent to CAD "designated" info, to which the NIST doc pertains? 206.47.249.252 (talk) 12:11, 10 June 2008 (UTC)