The 3DES (Triple DES) Algorithm

The 3DES (Triple DES) Algorithm

Introduction

As the 1990s rolled around, the 56-bit DES key was beginning to look sparse. Breaking a DES-encrypted message wouldn’t be trivial, though it could eventually be brute-force cracked. But replacing the protocol would take years of standardization, testing, and implementation. The neat, practical fix held us over for the next two decades. It was hardly a new invention.

It was just “encrypting DES three times,” with a different key each time.

This is called Triple DES or TDES. It’s a brilliant variant of an ancient algorithm.

Table of Contents

• Why Not Just Double DES?
• How 3DES Works: EDE
• Keying Options
• A Worked Example
• Python Implementation
• Limitations
• Security and Performance
• Why 3DES Is Being Retired Too
• FAQ
• References

Why Not Just Double DES?

The most obvious idea is encrypting with DES twice, with two different keys. It turns out to provide far less protection than intuition would suggest. Meet-in-the-middle: It turns out there’s a straightforward attack.

How 3DES Works: EDE

The meet-in-the-middle weakness of 2DES is avoided by doing three, rather than two, operations. This is called EDE (Encrypt-Decrypt-Encrypt):

Ciphertext = E(K3, D(K2, E(K1, Plaintext)))

Decryption reverses the process:

Plaintext = D(K1, E(K2, D(K3, Ciphertext)))

Another clever feature: you could use the same key three times, not three different ones. And it would reduce to single DES. Well, that’s because in the middle step you’re doing a decrypt, not an encrypt. But applying an encrypt and decrypt with the same key cancels out. That gives you back the original data.

Interactive Visualizer

Watch in the animation above as a 64-bit block goes through all three DES stages. K1’s stage acts as an encrypting layer. K2’s stage acts as a decrypting layer. K3’s stage acts as the last encrypting layer that creates the final ciphertext.

Keying Options

3DES has three different ways in which you can set up the keys. All of which involve some compromise between key management and security.

• Keying Option 1 uses three independent keys: K1, K2, K3. It’s the strongest option, with about 168 bits of nominal security. Attacks currently scale that down to about 112 bits.
• Keying Option 2 has K1 and K3 identical, but K2 is different. This is the most frequently used configuration. It provides about 112 bits of security using only two keys.
• Keying Option 3 sets all keys equal: K1 = K2 = K3. It degenerates to single DES. It’s included for backwards compatibility only, and doesn’t provide any security over simple DES.

A Worked Example

Using DES’s classic textbook key across all three positions demonstrates the backward-compatibility property directly:

• Key (all three positions): 133457799BBCDFF1
• Plaintext: 0123456789ABCDEF
• 3DES Ciphertext: 85E813540F0AB405. This is the same as plain old single DES. EDE structure actually collapses properly when all keys are equal.

And…that’s three different keys, so the visualizer above will reveal an entirely different final ciphertext. Again: computed through the same encrypt-decrypt-encrypt process.

Python Implementation

The EDE structure from above is only three function calls. These are, once a working DES block cipher is available. We reuse the des_encrypt_block and des_decrypt_block functions from the DES guide’s Python Implementation section:

from des import des_encrypt_block, des_decrypt_block  # the two functions from the DES guide's Python Implementation section

def triple_des_encrypt_block(k1, k2, k3, block):
    return des_encrypt_block(k3, des_decrypt_block(k2, des_encrypt_block(k1, block)))

def triple_des_decrypt_block(k1, k2, k3, block):
    return des_decrypt_block(k1, des_encrypt_block(k2, des_decrypt_block(k3, block)))

if __name__ == "__main__":
    key = bytes.fromhex("133457799BBCDFF1")  # same key in all three positions
    plaintext = bytes.fromhex("0123456789ABCDEF")

    ciphertext = triple_des_encrypt_block(key, key, key, plaintext)
    recovered = triple_des_decrypt_block(key, key, key, ciphertext)

    print(f"Plaintext:  {plaintext.hex().upper()}")
    print(f"Ciphertext: {ciphertext.hex().upper()}")
    print(f"Recovered:  {recovered.hex().upper()}")

Using all three keys the same, this exactly reproduces the worked example. The ciphertext is 85E813540F0AB405, the same as plain single DES. The EDE construction perfectly collapses as before.

Now try three distinct keys instead (Keying Option 1), and you’ll see a different ciphertext.

The visualizer above confirms that you will.

Limitations

This is a thin, trusting wrapper around actual DES. It has the same limitations as the underlying DES implementation that it is based on:

• Single 64-bit block only. As with the underlying DES functions, this just does a single 64-bit block. This means there is no mode of operation, no padding scheme. Non-8-byte messages won’t work.
• No key-strength validation. The code accepts three identical keys, unmolested. That is Keying Option 3, equivalent to single DES. You get no indication that it provides no additional security.
• Lack of timing-attack security hardening, as provided by the underlying DES implementation.
• The limitation here is not the code but 3DES itself. 3DES has a 64-bit block size, which is susceptible to Sweet32. That’s true even with a perfect implementation of the algorithm. This code isn’t designed to protect real data. It’s designed to illustrate the EDE construction.

Security and Performance

3DES with independent keys is substantially more secure than single DES, definitely. However, there is a significant drawback: it executes the DES algorithm 3 times. Consequently, it is roughly 3 times slower than single DES. Furthermore, on modern systems, it is significantly slower than AES. AES can utilize specialized AES-NI instructions that 3DES does not support.

The other major detail that 3DES inherits from DES is the tiny 64-bit block size. That alone introduces vulnerability beyond whatever the key strength is. If you encrypt over around 32GB under one key, you cross the birthday boundary. That opens the door to collisions. Those collisions will be visible in the ciphertext blocks.

This weakness was called the Sweet32 attack in 2016.

It applies to 3DES and Blowfish.

Why 3DES Is Being Retired Too

Though 3DES has been around for 20 years, it will now be replaced:

• 3DES was retired for new applications by NIST in 2017. It was banned in federal systems after 2023.
• Performance: considerably slower than AES, with no co-processor to accelerate the process.
• Block size: the 64-bit block does not lend itself to large volumes under one key. Well, Sweet32 proved it.

All the remaining 3DES implementations in use today are legacy implementations. For example, older payment terminals and other banking systems. They have not fully transitioned to AES.

FAQ

Is 3DES still secure?

It provides significantly better security than single DES. But a small 64-bit block and slow performance make it obsolete for new systems. Use AES.

Why does 3DES use encrypt-decrypt-encrypt instead of encrypt-encrypt-encrypt?

Applying decrypt to the middle operation ensures 3DES is backwards compatible with single DES. That is true when all three keys are the same. This is also the specific construction that NIST validated to resist known attacks. Triple-encrypt (EEE) provides no significant security benefit over EDE.

How many keys does 3DES actually use?

It depends on the keying option. Keying Option 3: uses 1 effective key, as all three are the same DES key. Keying Option 2: uses 2 independent keys, the most prevalent. Keying Option 1: uses 3 independent keys, the strongest but also the least prevalent.

What replaced 3DES?

AES was standardized in 2001. It has largely taken the place of DES and 3DES for almost all new systems. It’s faster and supports a bigger 128-bit block size. It also has dedicated hardware acceleration on modern microprocessors.

What is the Sweet32 attack?

A 2016 attack that exploits the small 64-bit block size shared by 3DES and Blowfish. Encrypt enough data under one key, and collisions start appearing between ciphertext blocks. This is especially likely in long-lived TLS connections. Those birthday-bound collisions can leak information about the plaintext. This happens even without breaking the underlying cipher’s key.

References

1. NIST SP 800-67 Rev. 2. “Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher.” Available at: https://csrc.nist.gov/publications/detail/sp/800-67/rev-2/final

2. Wikipedia. “Triple DES.” Available at: https://en.wikipedia.org/wiki/Triple_DES

3. Bhargavan, K. and Leurent, G. “Sweet32: Birthday Attacks on 64-bit Block Ciphers in TLS and OpenVPN.” 2016. Available at: https://sweet32.info/

4. NIST. “Update to Current Use and Deprecation of TDEA.” 2017.