TripleDES key sizes - .NET vs Wikipedia

Question

According to Wikipedia, TripleDES supports 56, 112, and 168-bit key lengths, but the System.Cryptography.TripleDESCryptoServiceProvider.LegalKeySizes says it only accepts 128 and 192-bit key lengths.

The system I'm developing needs to be interoperable (data encrypted by my code needs to be decryptable in PHP, Java, and Objective-C) and I don't who is correct in this case.

So who should I believe? And how can I be sure my encrypted data is portable?

Mutualism

Answer 1

Wikipedia does not say TripleDES supports 56 bit keys. The "keying options" talk about "triple-length" keys and "double-length" keys, the latter "reduces the key size to 112 bits". The effective key size for the original DES is 56 bit. Such a key is constructed from 64 bit input though, where 8 bits remain unused. The "triple-length" key option thus works with a three times 56 bit (=168) constructed from three times 64 bit (=192 bit) and the "double-length" option works with two times 56 bit keys (=112) constructed from two times 64 bit (=128).

As your TripleDESCryptoServiceProvider needs to derive the actual keys from the 64 bit-based input first, it will only take either 128 bits (double-length) or 192 bits (triple-length) as input and then internally derive the 168 or 112 bit actual keys from that input.

That's standard procedure for TripleDES, so you should have no problems with portability across platforms.

Anemology

three days of looking at useless examples then this answer helped me realise how .Net supports 128bit keys and the CCCrypt function forces you into 192bit... it copies the first 64bits of the 128bits onto the end so K3 = K1. iOS <-> C#.Net interoperability. So simple. – Taler

Answer 2

Triple DES will only use 112/168 bits of your 128/192 bit key. .NET asks for more bits for the purpose of alignment (each 56 bit subkey is aligned on a 64 bit boundary).

56 bit DES is broken and I'd expect they've made it harder to use.

Persuader

Answer 3

I believe some (all?) implementations of DES use only 7 bits per character of the key (ASCII encoding). I'm not sure if the definition of DES allows for 8-bit characters in keys or if it actually ignores the high bit of each byte. I think it's the latter.

However, in .NET key sizes are based on the number of bytes, times 8 bits per byte, even if the underlying algorithm ignores that top bit. That is probably the main discrepancy.

TripleDES runs DES three times with potentially three different 56-bit DES keys. In some implementations the middle run is reversed (encrypting-decrypting-encrypting or "EDE") so that using the same 56-bit DES key for all three duplicates the encryption of simple DES. This was done for compatibility with older systems where both are using hardware-based encryption. I'm not sure if the TripleDESCryptoServiceProvider uses this "EDE" approach or the "EEE" approach (or gives you a choice). Further, the same 56-bit DES key can be used for the first and third run, using a 112-bit key instead of the 168-bit key it could also use.

The certified TripleDESCryptoServiceProvider wouldn't accept 56-bit (64-bit) keys because it's not really 3DES security (you could use DESCryptoServiceProvider instead?). At one time it was determined that the 168-bit EEE (or EDE?) 3DES does not provide any greater security than using a 112-bit (128-bit) key. However, there may be some extreme (generally unavailable) attacks in which the shorter key is theoretically more vulnerable. That may also apply to the EDE vs EEE question.

On your compatibility vs other languages question, .NET's *CryptoServiceProvider classes are just a wrapper API around the underlying Windows CRYPTO library. If the other languages are also using the Windows CRYPTO library it should be compatible. Otherwise, you'd have to find out whether they are using EDE or EEE and make sure all are using the same one (you may or may not have flexibility on that), and obviously use the same key length. They are probably all using the same byte order, but if you find things still don't match up that might be another thing to check. Most likely on Windows they're all using CRYPTO and will probably match up as long as you can set the options the same way for all of them.

Piscatelli

Late, but: the definition of DES reserved the low bit of each byte of key for (odd) parity; in the 1970s crypto was done in dedicated discrete hardware and bit errors were a real possibility. Today with nearly everything in software or firmware some implementations ignore parity and some still check it for compabitility; I don't know which dot-NET (or CAPI) does. ASCII should not be assumed or required for key values, and certainly had nothing to do with the definition. ... – Prittleprattle

... Also, both EDE and EEE were considered back in the 1990s when it was apparent an "enhancement" of DES was needed, but only EDE was standardized and I'd be very surprised to find any implementation today doing EEE. – Prittleprattle

@Prittleprattle thanks for the clarification on the standardization with EDE. On the parity bit, it would be pretty lousy if the software implementation (translating into possible hardware implementation) took the upper 7 bits of each provided byte when there is more entropy in the lower 7 bits (in case an encryption password were provided directly--if perhaps foolishly). I would think it most sensible that it keeps the lower 7 bits of each byte and shifts them along with computed parity into the 3DES implementation. Of course, it could do something less sensible, instead, and lose entropy. – Piscatelli

Answer 4

Des uses multiples of 64 bit keys, but throws away 8 bits leaving a useful keylength of 64 bits.
Triple des can use double or triple key length.
However because repeating des with the same key decrypts the message running des an even number of times can partially decrypt stuff if the keys share patterns.

For this reason des is always ran an odd number of times.

This is also why you should never choose a key where 64 bit parts repeat.

With triple des 192 bit you thus have a effective key length of 112 bits

Constraint