Talk:Triple DES

Untitled

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)

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):=DES_k2(DES_k1(P)), ie. two DES encryptions with two different keys. 2-key 3DES is the operation 2KEY-DES3(P):=DES_k1(DES^-1_k2(DES_k1(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 2⁵⁶+2¹¹² operations and 2⁵⁶ 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

Interesting paper on this subject: http://www.jtc1sc27.din.de/sixcms_upload/media/3031/SC27N6706_SD12_20080421.pdf 206.47.249.252 (talk) 16:48, 28 October 2008 (UTC)

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)

Surely the "official" way to describe the "two key variant" is the way that it is defined in the standard itself - ie "Keying Option 2". This is the term used in all of: ANS X9.52-1998 Triple Data Encryption Algorithm Modes of Operation, FIPS PUB 46-3, ISO/IEC 18033-3:2005 Information technology — Security techniques — Encryption algorithms — Part 3: Block ciphers, as well as NIST SP 800-67. None of these use the term "2TDEA". I suggest that anyone interested in the topic should actually read the (freely available) standard FIPS PUB 46-3 and the Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher. Mitch Ames (talk) 06:47, 27 June 2008 (UTC)

See also my #Proposed rewrite to match the standards. Mitch Ames (talk) 12:26, 17 March 2009 (UTC)

I’ve added a new section "Other terms used to refer to the keying options" to list the terms ("3TDEA" etc) that are not used by the standards (X9.52, FIPS PUB 46-3, NIST 800-67, ISO/IEC 18033-3) that define the TDEA but are used by authoritative documents (eg NIST SP 800-78-1). This allows the article to mention those terms while clearly separating them from the "official" term "keying option". I suggest that new terms should only be added here if citations can be provided to authoritative documents, eg those from recognised authorities (FIPS, NIST, ISO etc). Mitch Ames (talk) 14:57, 28 May 2009 (UTC)

I suspect that a table might be more readable than the current indented bullet list, especially if more terms are added, but I’ll leave that for another day or another editor. Mitch Ames (talk) 14:59, 28 May 2009 (UTC)

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)

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 2⁵⁸ operations and 2⁵⁶ 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 2⁵⁶ 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)

More on origin

Following up on the above, I found this reference (http://cs.jhu.edu/~sdoshi/crypto/papers/p465-merkle.pdf): "At the 1978 National Computer Conference, Tuchman [12] proposed a triple encryption method which uses only two keys, K1 and K2." This is in a section heading titled "Triple Encryption" that follows additional discussion of Double Encryption and the introduction to this section begins with "Diffie and Hellman [2] have argued that the 56-bit key used in the Federal Data Encryption Standard (DES) [9] is too small and that current technology allows an exhaustive search of the 256 keys." This may serve as a better reference to clarify the origin. Currently the summary box saying 1995 as the "first published" date is misleading I think.

The above note was made in this diff. Indeed, I have added a reference to Merkle/Hillman 1981 and note the 1978/1981 origins of 3DES. Samboy (talk) 14:56, 31 December 2021 (UTC)

Clarification Needed, etc...

The security section (http://wiki.riteme.site/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 2⁸⁸ 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 2⁶⁶ bytes, and can store "merely" 2⁶³ 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 2⁸⁴ 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://wiki.riteme.site/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)

Proposed rewrite to match the standards

I propose to rewrite a significant proportion of this article to bring it in line with the following standards, which define the Triple Data Encryption Algorithm commonly known as Triple DES:

• FIPS PUB 46-3 Data Encryption Standard (DES)
• ANS X9.52-1998 Triple Data Encryption Algorithm Modes of Operation
• ISO/IEC 18033-3:2005 Information technology — Security techniques — Encryption algorithms — Part 3: Block ciphers

and this related standard:

• NIST Special Publication 800-67 Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher

In particular the changes will include:

• Removal of references to "EEE", because the standards don't mention it.
• Replacement of "2-key" and "3-key" with Keying Options 1, 2, 3 (as defined in the standards).

My work in progress can be found in my sandbox. I would appreciate any feedback as I go, but (aside from pointing out or correcting minor errors) please refer to the freely available FIPS PUB 46-3 first. Mitch Ames (talk) 12:26, 17 March 2009 (UTC)

Rewrite completed. Mitch Ames (talk) 08:46, 21 March 2009 (UTC)

CBCM ("Inner triple") mode should be mentioned.

It's really a completely separate (and flawed) 3-key mode of DES, but Coppersmith's "inner triple" mode is sometimes referred to as 3DES. It should probably be at least touched upon here. —Preceding unsigned comment added by Tls (talk • contribs) 08:04, 1 December 2009 (UTC)

Just because someone calls something "3DES" doesn't mean that it is 3DES, so I disagree that it should be described here. However it might be appropriate to create a new article for the "inner triple" mode, and list that article under Triple_DES#See_also. Mitch Ames (talk) 12:32, 1 December 2009 (UTC)

Schneier's Applied Cryptography describes both "outer triple" (what is called "Triple DES", and what you and I are calling "3DES", here) and "inner triple" (Coppersmith's CBCM mode) DES in the section on triple DES. They're basically given equal billing -- and this was pretty much the case in every reference I know of written before or even around when the problems with CBCM mode were discovered. So it was a very common usage -- consider that something as common as version 1 of the SSH remote-login protocol implements *only* CBCM mode as "3DES" -- and I think it should be treated here, not elsewhere. Tls (talk) 05:14, 16 December 2009 (UTC)

Note that I am not calling anything "3DES". Neither does the article, nor any of the standard referred to therein.Mitch Ames (talk) 14:03, 16 December 2009 (UTC)

Um. You call something "3DES" in your text directly above! Will you please stop this nitpicking and accept some constructive suggestions rather than treating the article text you wrote as magical and holy? The plain fact of the matter is that c. 1994-1998 -- when triple DES modes first came into widespread use -- if you talked to a cryptographer about "3DES", "Triple DES", "TDES", "TDEA", etc. you would quickly have to make it clear whether you meant "outer triple" or "inner triple" mode! That fact is plainly reflected in the Schneier book, which is by far the most popular desk reference on cryptography for implementers, and should not be ignored here; a short paragraph distinguishing between the old inner-triple and now almost universal outer-triple modes would save much confusion on the parts of people actually trying to use this article as a reference rather than trying to freeze the language of various standards in amber. Tls (talk) 23:30, 17 December 2009 (UTC)

I didn't "call something 3DES" - I merely stated that someone else calling something 3DES does not make it so.
Can you provide a reference for your claim that Schneier is the most poular reference for implementors? I would expect that any implementor worth his/her salt would implement as per the standard, from the standard - certainly I did, when I implemented it. Perhaps you can cite an earlier version of one of the standards that mentions "outer triple" or "inner triple". Also, it would probably help this discussion if you could quote the relevent parts of Schneier.
So far as "freezing the language of the standards" is concerned, surely the article is most useful if it actually matches the standards that it describes? Mitch Ames (talk) 16:12, 18 December 2009 (UTC)

I still assert that Triple DES is the block cipher defined in each of the standards mentioned in the article, and none of those standards (all of which I have checked) include "inner triple". Remember that "DES" is the Data Encryption Standard, not the Data Encryption methods used by some people but not defined in a standard. There may well be other modes of use of DES that involve three iterations, but they are not "Triple DES". Mitch Ames (talk) 14:03, 16 December 2009 (UTC)

I don't think your argument holds water -- the standards consistently refer to what you're calling "DES" as *"DEA"*, "Triple DES" as "TDEA" etc. When the original FIPS publication was propagated, to my knowledge nobody had ever publically proposed any multi-key ciphers using DES as the basic block transform at all! The fact of the matter is that as multi-key modes came into use there were two different popular ones, both of which were referred to by the several names given here: 3DES, Triple DES, etc, and distinguished as "outer" and "inner" modes. If you want to for some reason constrain this article to the language of standards which were published long after the article's subject came into common use, for consistency's sake you should also be proposing to rename this article "Triple DEA" or "TDEA" and the "DES" article to "DEA" -- but that's absurd, of course. Better by far to simply explain to the reader the different usages which are actually common among those working in the field. Oh, and by the way, the DES standard is in the process of being withdrawn -- should we rename the article then, since it won't be a "standard" any more? I think that, too, is a poor idea... Tls (talk) 23:30, 17 December 2009 (UTC)

<quoting Tls> ... as multi-key modes came into use ... there were two different popular ones, ... "outer" and "inner" modes <end quote>
Please provide a specific citation for this claim. My claims as to the algorithm are all easily verified by checking the standards - two of which (FIPS PUB 46-3 and SP 800-67) are freely available.
<quoting Tls> you should also be proposing to rename this article "Triple DEA" or "TDEA" and the "DES" article to "DEA"... <end quote>
I did consider that, but: 1) some of the standards themselves use Triple DES and DES - as mentioned in the the article. 2) WP:COMMONNAME apples.
<quoting Tls> ...the DES standard is in the process of being withdrawn -- should we rename the article then... <end quote>
The article explicitly mentions that FIPS PUB 46-3 is withdrawn - but the other three defining documents are all still current (as far as I know). Mitch Ames (talk) 16:12, 18 December 2009 (UTC)

Ironically, I had the Coppersmith mode which *did* make it into the standard (ANSI X9.52 CBCM mode) and the one which was actually in common use but was *not* standardized (inner triple CBC -- if the construction isn't due to Coppersmith, he was one of the first to analyze it) mixed up. What can I say? Biham has the best attack on each, both are much weaker than outer-triple-CBC, and I guess I shuffled them in my head since I haven't even thought of using either one in about a decade. The Schneier book isn't available online. However, some convenient references which do give a view of what was common usage wrt "triple DES" (or any other triple construction from any common cipher) in the early 1990s before there *were* any standards. Helena Handschuch's "On the Security of Double and 2-key Triple Modes of Operation": http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.3.8723&rep=rep1&type=pdf has a nice historical summary; references 9 and 10 there are Coppersmith's papers from the early 1990s on attacks on inner CBC, one of which is titled "A chosen-plaintext attack on 2-key inner triple DES CBC/EDE (1995)". Versions 1 and 1.5 of the SSH protocol used inner-triple-CBC, calling them both "Triple DES" and "3DES" and making no particular distinction from the now-standard outer-triple mode: see http://www.snailbook.com/docs/protocol-1.5.txt which helpfully mentions on page 5 "(Note: the variant of 3DES used here differs from some other descriptions.)" -- my distinct memory, having implemented from this spec, is that earlier versions didn't include the "Note"! And the cryptographic library which eventually became OpenSSL, Eric Young's libdes, originally implemented only inner-triple mode as well -- this can be hard to grasp from the documentation but the mailing-list thread at http://archives.neohapsis.com/archives/crypto/2000-q4/0107.html delves into the sordid history a bit. As an aside, http://www.ddj.com/architect/184409815?pgno=2 contains the interesting tidbit that the first mention of multiple DES in a standards document was ECB mode in ANSI X9.17-1985, used to encrypt keys for other cipher modes.

Finally, since many general works on cryptography (Schneier, also "Handbook of Applied Cryptography" http://www.cacr.math.uwaterloo.ca/hac/about/chap7.pdf (see the end of section 7.2) which you can easily find online) describe inner-CBC, it may be worth mentioning here simply to make clear that the"interleaved" TCBC-I mode of ANSI X9.52 is *not* inner triple mode, but something much safer.

The bottom line: I was an idiot to confuse CBCM mode and inner-triple-CBC, particularly since at one point or another I implemented each from the original descriptions in the papers I confused -- but I hope the sampling of period literature above will help persuade you that, really-truly, in the early 1990s when multiple encipherment modes with DES were becoming common but there was no standard, if you said "triple DES" you had to specify whether you meant inner or outer chaining; and that that persists in a few common protocols designed even *after* Biham pretty much settled the debate and still deployed now that TDEA is actually standardized, most notably SSHv1. I do therefore think at least passing mention that inner-triple mode exists, isn't what's standardized, and shouldn't be used, is warranted in the article. Tls (talk) 07:26, 19 December 2009 (UTC)

Are there any standard protocols or common applications that use inner-triple DES? This is the first time I've heard of it. Nevertheless I think a 1-2 paragraph section is justified in this article. -- intgr [talk] 13:56, 18 December 2009 (UTC)

I concede that there may be "non-standard variations" (ie implementations that do not comply with current or past versions of the X9.52, FIPS 46-3, SP 800-67, ISO/IEC 18033-3) in use, and that there is a reasonable argument that those variations should be mentioned. However I also feel strongly that there should be a clear distinction between the standard algorithm (as defined in the aforementioned documents), and non-standard variations. Perhaps we should add a new section: "non-standard variations", which includes (as Tls suggests) an explicit statement that these variations are not part of the standard(s).Mitch Ames (talk) 12:17, 20 December 2009 (UTC)

Something else that we need to be aware of is that the TDEA (as specified in the standards) only covers a single block. Multiple block support, eg CBC etc, is not part of TDEA/Triple DES (see Triple_des#Encryption_of_more_than_one_block) - although it appears that it may be implicitly required by these "inner" and/or "outer" modes (I haven't yet read HAC to check). This may require an explicit mention in the new section. Mitch Ames (talk) 12:28, 20 December 2009 (UTC)

I don't think that's correct. X9.52 defines many block-chaining modes, including some very unusual ones such as CBC-I which I don't think I've ever encountered with any other cipher; and the penultimte draft included at least one (CBCM) which isn't in today's standard. Unfortunately the standard is not available in free form online -- it costs $100 -- I need to dig up my paper copy, it's been so long since I worked with it. Tls (talk) 03:36, 21 December 2009 (UTC)

X9.52-1998 (of which I have a copy) does indeed specify seven modes of operation: TECB, TCBC, TCBC-I, TCFB, TCFB-P, TOFB, TOFB-I. The important question is whether or not the "Triple DES algorithm" includes the modes of operation (as opposed to requiring them for multiple blocks). I suggest that it does not, because FIPS PUB 46 and ISO/IEC 18033-3 do not include them. (ISO/IEC 18033-1 clause 4.2.1 refers to ISO/IEC 10116, which defines modes of operation independently of the block cipher.) X9.52 clause 6.1 defines "TDEA Encryption/Decryption Operation" (of one block) independently of the modes of operation (which are in section 6.3). Also note that all of the modes of operation are wrappers to the core TDEA - those same modes of operation could be applied to any other block cipher algorithm (eg as some of them are to DES/DEA in X3.106 Data Encryption Algorithm - Modes of Operation, and to any n-bit block cipher by ISO/IEC 10116). X9.52 defines both TDEA ("Triple DES", the subject of this article) and also modes of operation (a separate Wikipedia article), but that does not need to imply that "Triple DES" per se includes modes of operation. Note that X9.52's title is "Triple Data Encryption Algorithm Modes of Operation", not "Triple Data Encryption Algorithm". I believe the Triple DES article already covers this requirement-but-not-inclusion in Triple_DES#Encryption_of_more_than_one_block. As previously mentioned a new section on "variations from the standard" might need to state that some of these variations necessarily implied a particular mode of operation, but I believe that we should be mindful of the fact that when referring to current standards, "TDEA" or "Triple DES" may require a mode of operation for multiple blocks, but that the mode of operation used isn't part of "TDEA" or "Triple DES". Mitch Ames (talk) 06:22, 21 December 2009 (UTC)

ANS or ANSI X9.52

I've reverted recent changes to the X9.52 references so that they say "ANS" rather than "ANSI". This is because I have a copy of X9.52-1998 in front of me and it clearly says ANS, not ANSI. The original note 1 noted the discrepancy between the copy used for reference and the current ANSI store designation. (It would have been helpful if someone had read that note when doing a search-and-replace. The edited note said "ANSI's ... website lists .. the standard as ANSI X9.52, but a printed copied ... is marked ANSI X9.52", which is less then sensible.) A Google search for "ANS X9.52" will find plenty of references to that designation - although also plenty of "ANSI X9.52" references. However X9's own catalog (from here), published March 2010, includes references to ANS X9.52.

It's most likely that ANSI and/or X9 have simply changed the way that they designate the standards (from ANS to ANSI) since 1998, and we should reflect that in the article somehow - presumably more so than the existing note. It may be appropriate to refer to ANSI in general, but I think that the explicit mention of "The earliest standard that defines the algorithm (ANS X9.52, published in 1998)" should retain the original designation, ie as it was published at the time.

Some questions I think we should answer before we update the article:

1. Does anyone have a access to a copy of ANSI (with an 'I') X9.52 to verify that it actually is ANSI, and not ANS. The reason that I reverted the article to ANS is because I have a copy of the standard with that designation - so "ANS X9.52" is my reference, not "ANSI X9.52".
2. If so, does it mention that it was originally published as ANS (with no 'I') X9.52?
3. Does anyone know for sure - and ideally point to a website as a reference - that ANSI/X9 changed the designation of their standards (without changing the content, or releasing a new version)?

Mitch Ames (talk) 06:29, 16 May 2010 (UTC)

I've just received an e-mail from X9 (in response to my enquiry to them), which says:

... at some point in the last few years the ANSI designation on standards changed from "ANS" to "ANSI". As standards are revised the ANS designation will change to ANSI.

I'm still chasing more specific details, eg has X9.52 actually changed yet (given that it has not been revised), is there a web page I can cite. Mitch Ames (talk) 01:05, 18 May 2010 (UTC)

According to my latest e-mails from X9:

It was last designated as ANS X9.52-1998

... not ANSI

X9.52 is no longer an active standard. It was withdrawn in 2008

I'm trying to find a web page (or other easily verifiable source) that states this, for citation purposes. The e-mail suggests that X9.52 may be removed from webstore.ansi.org soon - and in fact it now has been - and that:

The standard is due to be replaced by ISO TR 19038, but the document has not been approved by ISO yet.

In fact, ISO/TR 19038:2005 is available, but under review, and revised by ISO/DTR 19038. Mitch Ames (talk) 02:28, 23 May 2010 (UTC)

"Definitive standards" section

Wikipedia has a strong convention of of keeping sources/references/external links at the end of the article. I don't see why the "Definitive standards" list in this article should be an exception. And how about renaming it to something simpler like "Standards" or "3DES standards"? -- intgr [talk] 16:24, 31 May 2010 (UTC)

I agree that there is a strong convention for keeping references at that end of the article, however in this case the standards are not just "references" - they are an integral and necessary part of the statement "the TDEA is defined in [these standards]". This article is not about any encryption algorithm - it is about a specific algorithm, defined in specific standards, which is why I believe that the article should include an explicit statement to that effect. That's why I previously included that statement in the lead section. As per WP:LEAD, "The lead ... should define the topic", and per WP:MOSBEGIN "The first paragraph of the introductory text needs to unambiguously define the topic. (Admittedly "without being overly specific", but I think the former takes precedence here.)

Perhaps the lead section should start with a shorter definition, such as "In cryptography, Triple DES is the common name for the Triple Data Encryption Algorithm (TDEA) block cipher defined in each of several standards: ANS X9.52, FIBS PUB 46-3, NIST SP 800-67 and ISO/IEC 18033-3:2005." with ref tags after each standard designation so the the full name and external link (ie as it is now) appear in the References section. This would follow the convention of listing references at the end, while meeting the requirement to define the topic in the lead section. Of course this makes our lead sentence somewhat "cryptic" with only the standard designations and no names. I think that WP:IGNORE should apply here to the convention of listing references at the end.

As far as the section name "Definitive standards" it is accurate - the listed standard are definitive standards, ie those that define the standard. This section would disappear if the definition were moved back to the lead section. Mitch Ames (talk) 13:45, 3 June 2010 (UTC)

Wikipedia has many thousands of articles about ciphers and standards, yet no established articles that I have seen are structured like this. If someone wants to find the actual standards for the algorithm, they'd probably be looking at the end. But most readers only want an overview of 3DES. As I said, this article is not an exception by any means. The word "define" in WP:LEAD refers to providing a definition for the term; a definition should be concise and not rely on whole publications.

As for the lead section, I think it's fine right now (apart from the "sometimes also referred to as" — why not keep it short and to the point? According to a Google test, the term 3DES is three times as popular as triple DES). -- intgr [talk] 19:11, 3 June 2010 (UTC)

In deciding how the article should be structured, in particular how and where the standards should be listed, consider the following: The article is about a specific algorithm. Thus we must surely state explicitly which algorithm we are talking about. An important reason for using this algorithm is that it is a standard, ie it is well-defined in documents from recognized standards publishers (ANSI, NIST, ISO/IEC). Thus when stating what algorithm we are talking about (ie "defining the topic" of the article), the obvious, accurate and concise way to do so is "the algorithm defined in [the standards]". If we restrict "[the standards]" in this sentence to designation only (ANS X9.52, FIBS PUB 46-3, NIST SP 800-67 and ISO/IEC 18033-3) - as I suggested in my comment of 3 June 2010 - the definition is concise and accurate. Also consider that WP:LEAD says "The lead should be able to stand alone as a concise overview of the article." I believe that a stand-alone overview should include the important statement that Triple DES is an algorithm defined in specific standards. The main principle here is that the standards are not just references "that verify the information in the article", they are an integral part of the definition of the article's topic.

Again, I suggest that the lead section should include "... defined in each of several standards: ANS X9.52, FIBS PUB 46-3, NIST SP 800-67 and ISO/IEC 18033-3:2005". Ref tags after each standard designation would put the full name and external link (ie as it is now) in the References section. However I still believe that in the interest of clarity (one of the WP:MOS general principles) and readability, the full standard name should appear in the body of the text (as it does now). In either case the "Definitive standards" section would disappear.

Regardless of how other articles may be structured (and bear in mind that WP:MOS includes "style ... should be consistent within a Wikipedia article, though not necessarily throughout Wikipedia as a whole"), I think that my proposal here meets all of the MOS guidelines and policies. Mitch Ames (talk) 14:22, 4 June 2010 (UTC)

I disagree, but I won't continue this argument. -- intgr [talk] 12:04, 11 June 2010 (UTC)

On "3DES": I had included "sometimes referred to" because the term is not included in any of the defining standards. However, you're correct - the term is clearly common, and close enough to an acronym, so I've removed the extra text and added the google search as a "reference". Mitch Ames (talk) 04:12, 4 June 2010 (UTC)

IBM's use of DES keys

I've deleted IBM's terminology for DES keys (triple-length, double-length, single-length) keys (again), because the cited reference does not mention Triple DES at all, only DES. This article is about the Triple DES algorithm (as defined in the referenced standards), not IBM's use of DES. Mitch Ames (talk) 12:29, 13 June 2010 (UTC)

Perhaps you should read the other reference I gave which describes "double length key" and its use in Triple DES, but which was also deleted. The second reference you object to shows the term in common use. Here's another reference to the term, including the words "Triple DES". The term "double-length key" is confusingly used in plenty of documents (including the keys.htm link above) - which is why I came to make it clear in Wikipedia in the first place. The terms triple-length, double-length and single length key is used by manufacturers of HSMs including IBM, Thales, Safenet and Sun to describe the keying options used in Triple DES. Wasn't your curiosity piqued when you saw the inventor of DES (IBM) use a term to describe keys which isn't referenced in the wikipedia DES page? Dkam (talk) 11:09, 10 July 2010 (UTC)

I think I missed your IBM Triple DES reference because you added it with a comment "Undid revision ... by Mitch Ames", but my edit that you appeared to be undoing was removing your edit that did not include the IBM Triple DES reference - only the Types of Keys reference, which does not mention Triple DES at all. In short: I didn't notice the reference because you used a misleading comment when you added it. However, since we do now definitely have a couple of references that mention double/triple length keys and Triple DES (not just DES), I've restored (with some rewording) the "Other terms used to refer to the keying options" subsection, with references. Mitch Ames (talk) 10:55, 12 July 2010 (UTC)

I agree that my comment when reverting your revert wasn't sufficiently clear - I'll keep that in mind. As to missing the reference - it was another user who deleted it. An unfortunate sequence of events. Dkam (talk) 09:37, 26 July 2010 (UTC)

DES EDE

Should there be an explicit mention of calling the TDEA algorithm DES EDE? It is even in the comments here, but it isn't mentioned in the article. Note that I would have added something in the line "None of the standards that define the algorithm use the term "3DES" or appending that sentence to include "DES EDE", but I'm not sure the term isn't used in *any* of the standards. In the same line, sometimes the keys are called DES ABC keys for scheme 1 and DES ABA keys for scheme two (although that does not seem to comply with the order of the keys used by NIST, which starts encryption with Key 3).

"EDE" is not (to my knowledge) a common abbreviation for Triple DES, so it doesn't get a mention in the article. ("3DES" is quite common, so redirects to Triple DES, which is why it is mentioned in the article.) Likewise "ABC keys" and "ABA keys" are not mentioned or common in "other standards and related recommendations, and general usage". It's not feasible or appropriate to mention every variation in the terminology that has ever been used by anybody - that will simply cause more confusion for the readers.

"the order of the keys used by NIST, which starts encryption with Key 3" - All four of the standards listed in Triple_DES#Definitive_standards - of which both NIST publications are freely available for you to check, just click on the link - state that TDEA encryption encrypts with K1 first. Feel free to quote the exact clause of any standard that you think says otherwise, and I'll try to clarify it. Mitch Ames (talk) 13:41, 26 June 2012 (UTC)

More detailed description of key format?

Currently there is one tiny reference to the presence of parity bits within the article. I believe a new section should be added which explains how Triple-DES keys are stored, explaining the parity bits and noting that the total stored key size is then 192-bits. Duncan Jones (talk) 15:53, 4 March 2013 (UTC)

The parity bits are a function of DES, rather than Triple DES. Data Encryption Standard#Description talks about the parity bits, but even that's a bit light on the details. It probably wouldn't hurt to mention explicitly in the DES article that:

• it's odd parity (ie not even, space or mark parity) - Reference: FIPS PUB 46-3, and probably also the other standards
• DES keys are typically stored as 8-byte blocks, with the least significant bit being the parity bit - but do we have a reference for this?

and then in the Triple DES article, that:

• the keys are typically stored as 24, 16 or 8 bytes (keying options 1, 2, 3), with LSB of each byte being parity - but again {{Citation needed}}

I'll put something in the article(s) when I get some time.

The "odd parity" is straight-forward - FIPS PUB 46-3 says so. Do you have a reference of 8-byte blocks and LSBit parity? Mitch Ames (talk) 11:42, 6 March 2013 (UTC)

I've update the DES article, and the Triple DES article to provide a bit more on the parity bits and the number of bytes used to store the key(s). It turns out that the standards explicitly mention the use of 8-bit bytes for the keys. I've not mentioned LSB - and limited the description to the bit numbers - because the standards only talk about bit numbering, not most- or least-significant bits. Because the keys are not actually numbers the issue of most/least significance does not apply. Endianness of storage or transmission is a separate issue that I don't want to try to cover here. Mitch Ames (talk) 08:49, 9 March 2013 (UTC)

SSL

Which of the keying methods is actually used in the various 3DES/DES3 ciphersuites of SSL? Is this client-specific (in which case I’d be interested in OpenSSL 0.x, 1.x, GnuTLS 3, SChannel) or not? mirabilos (talk) 10:43, 8 January 2015 (UTC)

I'm not an expert on SSL, but Open SSL appears to support keying options 1 and 2 (aka "three key", "two key"). Mitch Ames (talk) 12:54, 8 January 2015 (UTC)

Quotation from RFC 2246 (TLS 1.0).

DES can also be operated in a mode where three independent keys and three encryptions are used for each block of data; this uses 168 bits of key (24 bytes in the TLS key generation method) and provides the equivalent of 112 bits of security. [DES], [3DES]

In TLS/SSL, keying options 1 is used. --Claw of Slime (talk) 14:51, 8 January 2015 (UTC)

Sweet32

With https://sweet32.info/ affecting 3DES, I think this should be mentioned somewhere in the security section, shouldn't it?

129.104.247.2 (talk) 08:35, 4 November 2016 (UTC)

Not necessarily. Sweet32 applies to all 64-bit block ciphers not just (triple-)DES, and applies only in conjunction with block cipher mode of operation rather than the block cipher alone. Mitch Ames (talk) 03:47, 5 November 2016 (UTC)