3DES 128 bit encryption does not exist

Understanding how to describe a cryptographic key in terms of "number of bits" can be tricky. Do you mean exactly how many bits comprise the key? That might not be very useful because algorithms like DES and 3DES don't actually use all of the bits in a key. A DES key actually has 64 bits, but eight of these are parity bits and aren't used to encrypt or decrypt, leaving only 56 bits for that.

Another definition is based on how much cryptographic strength a key provides. This is probably more useful, but it adds another source of confusion. A 3DES key has 192 bits, but only 168 are actually used to encrypt or decrypt. But when 3DES is used, there are attacks against it that reduce the strength provided by those 168 bits to about 112 bits.

That's too much information for most people, and it's really more than you should expect a non-specialist to understand.

On the other hand, it's definitely the sort of thing that any security vendor should know and understand. This is why I was surprised to see the term "3DES 128 bit encryption" again and again in Shift4's white paper Storing Credit Card Data.

I was surprised because 3DES 128 bit encryption doesn't exist.

Depending on your point of view, you might say that a 3DES key has either 192 bits or 168 bits. You might even say 112 bits if you're thinking about bits of strength instead of how many bits comprise a key. There's no way at all to justify saying that one has 128 bits.

You shouldn't expect the average guy on the street to know this, but it's the sort of thing that a security vendor really ought to know.

This error probably comes from a misunderstanding of an earlier version of the PCI DSS audit procedures that wasn't as clear as it could be. In particular, the testing procedures for version 1.1 of the PCI DSS had this:

3.4.a Obtain and examine documentation about the system used to protect stored data, including the vendor, type of system/process, and the encryption algorithms (if applicable).

Verify that data is rendered unreadable using one of the following methods:

• One-way hashes (hashed indexes) such as SHA-1

• Truncation or masking

• Index tokens and PADs, with the PADs being securely stored

• Strong cryptography, such as Triple-DES 128-bit or AES 256-bit, with associated key management processes and procedures

Note that the last bullet point isn't written as clearly as it could be. It looks like a combination of a missing comma and a cut-and-paste error. What they probably meant was this:

• Strong cryptography, such as Triple-DES, 128-bit or 256-bit AES, with associated key management processes and procedures

A security vendor should have been able to see the problems with the last bullet point and not just copied the confusing text. They certainly should have known that 3DES 128 bit encryption doesn't exist.

  • lance

    Hi Luther;
    I’m not associated with shift 4 but have been i the payment terminal business for a while now. I think they are referring to 2TDEA – 2 key Triple Data Encryption Algorithm (DES). Exactly because of the weakness you mention, many TDEA users decided to use 2TDEA to simplify key management, as it was originally thought that 2 keys were almost as good as 3. It seems a weakness was found with 2TDEA showing it is not nearly as good as was once thought, but still much better than standard DES – good enough for NIST to condone it’s use through 2010.
    This is a relatively new recent recommendation from NIST.
    see SP 800-57 part 1.
    The current standard for PIN Encryption is 2TDEA with DUKPT key management (Typically referred to as Triple DES DUKPT, the practice calls for 2 keys). The nature of DUKPT is such that 2TDEA may be sufficient for some time beyond 2010. It is interesting that even though most terminals and PIN Pads have supported 2TDEA DUKPT for years, many acquires are only now providing support on their end.


Leave a Reply

Your email address will not be published. Required fields are marked *