From DES to Post-Quantum Cryptography: The Arms Race

Modern cryptography is not simply a sequence of stronger ciphers; it is a sequence of solved trust problems. Symmetric encryption protects bulk data when both parties share a secret. Public-key cryptography helps establish keys and sign messages. Hash functions create compact integrity evidence. Certificates bind keys to identities. TLS composes these pieces into protected communication—provided implementation, configuration and key management are sound.

This guide follows DES in 1977, Diffie–Hellman, RSA, the open AES competition, successive TLS versions and NIST’s first post-quantum standards. Older decisions explain current failures: encryption without authentication, expired certificates, static shared keys and migration delayed until an algorithm becomes an emergency.

Cryptographic functions

Need	Mechanism	Examples
Bulk confidentiality	Symmetric cipher	AES-GCM, ChaCha20-Poly1305
Shared-secret establishment	Key exchange / KEM	(EC)DHE, ML-KEM
Authenticity	Digital signature	RSA-PSS, ECDSA, ML-DSA
Message integrity	MAC or AEAD	HMAC, AES-GCM
Data fingerprint	Hash	SHA-256, SHA-3
Bind a key to a name	Certificate and PKI	X.509, certificate authority

An algorithm is not a protocol. AES defines a block transformation but does not specify nonce creation, key transport, peer authentication or error handling. TLS defines negotiation, key schedules, records and messages while composing several primitives.

1976: Diffie and Hellman publish a new direction

Before public-key cryptography, two parties needed a securely delivered shared secret. In a large network, pairwise key distribution becomes a logistical barrier.

Whitfield Diffie and Martin Hellman’s 1976 “New Directions in Cryptography” described public information exchange that leads both sides to the same secret. Classic Diffie–Hellman security relies on the difficulty of discrete logarithms in a suitable group.

Diffie–Hellman alone does not authenticate a peer. An active attacker can establish separate secrets with both parties and relay traffic. A signature, certificate or previously known key is required. Confidentiality without authentication does not prevent a man-in-the-middle.

Ephemeral DHE and ECDHE create fresh session keys. Later compromise of a long-term signing key should not decrypt previously recorded sessions. This forward secrecy is a standard property of TLS 1.3.

DES: the first public US federal cipher standard

The Data Encryption Standard was published as FIPS 46 in January 1977. DES encrypts 64-bit blocks with an effective 56-bit key. Standardisation enabled interoperability and public analysis. Controversy focused on key length and NSA influence over S-box design.

As hardware improved, 56 bits became too small. The EFF DES Cracker demonstrated practical key search in 1998. Triple DES extended deployment life by applying DES three times, but remained slow and retained a small block size.

DES shows that a parameter’s safety declines with economics. A cipher need not suffer a new mathematical break to become operationally unacceptable.

1978: RSA combines public-key encryption and signatures

Ronald Rivest, Adi Shamir and Leonard Adleman published a method using arithmetic modulo a product of large primes. A public key can encrypt or verify signatures, while the private key decrypts or signs. Security is linked to the difficulty of factoring an appropriately large modulus.

“Textbook RSA” must not be used without an encoding scheme. Deterministic encryption is vulnerable and raw signatures lack safe structure. OAEP for encryption and PSS for signatures add randomness and analysed formatting.

RSA became common in certificates and older TLS key exchange. TLS 1.3 removed static RSA key exchange. An RSA certificate may still sign the handshake, but session secrets derive from (EC)DHE or PSK, preserving forward secrecy.

Hash functions and the collision lesson

A cryptographic hash maps arbitrary data to a fixed-length value. Desired properties include preimage, second-preimage and collision resistance. For an ideal n-bit hash, collision search costs roughly 2^(n/2) because of the birthday effect.

MD5 and SHA-1 lost collision resistance. That does not make every observed digest reversible, but it invalidates safe use in certificates and document signatures where an attacker may prepare two contents. Migration to SHA-256 and SHA-3 demonstrates the need for crypto agility.

Passwords should not be stored as a fast unsalted hash. They need Argon2id, scrypt, bcrypt or PBKDF2 with unique salts and cost parameters. SHA-256 is deliberately fast, which benefits offline guessing.

The AES competition

NIST began a public successor competition in 1997. Fifteen algorithms were submitted and analysed at open conferences. NIST selected the Rijndael family by Joan Daemen and Vincent Rijmen in 2000 and published FIPS 197 on 26 November 2001.

AES uses 128-bit blocks and 128-, 192- or 256-bit keys. The block cipher still needs a mode. ECB exposes repeating structure. CBC requires unpredictable IVs and correct authentication composition. Modern protocols prefer AEAD, combining encryption and authentication.

AES-GCM is efficient and hardware accelerated, but nonce reuse with one key can be catastrophic. ChaCha20-Poly1305 performs well without AES acceleration. Primitive choice does not replace sound nonce and key lifecycle design.

From SSL to TLS 1.0

Netscape developed SSL for protected web commerce. SSL 2.0 had serious defects; SSL 3.0 became the basis for IETF standardisation. TLS 1.0 was published as RFC 2246 in January 1999. It negotiated versions and cipher suites, authenticated servers with certificates, established secrets and protected records.

Flexibility supported compatibility while keeping weak options alive. CBC padding, renegotiation, RC4 and downgrade attacks showed that a protocol is only as strong as its weakest negotiable path and implementation. POODLE exploited fallback to SSL 3.0; later standards prohibited legacy versions and ciphers.

TLS 1.3: fewer options and stronger defaults

TLS 1.3 arrived as RFC 8446 in August 2018. It removed static RSA and DH key exchange, legacy ciphers, record compression and non-AEAD suites. Public-key exchanges provide forward secrecy. Handshake messages after ServerHello are encrypted, and HKDF separates secrets.

The shorter handshake reduces latency. 0-RTT sends early data during resumption but permits replay. Applications should only allow replay-safe operations—not payments or state changes—in early data.

A practical TLS 1.3, mTLS and PKI audit checks protocol version plus certificate chain, names, rotation, key protection, revocation and trust stores.

PKI: mathematics meets operations

An X.509 certificate signed by a trusted CA binds a public key to names and validity. Clients build a chain to a trusted root and check signatures, hostname, time and constraints. Failures more often involve expired certificates, wrong names, accidental CA trust or private-key leakage than broken AES.

mTLS authenticates clients with certificates for strong machine identity. It does not replace authorisation: a certificate states who the client is; policy determines allowed actions. Automated enrolment, short validity and rotation make PKI sustainable.

2024: NIST’s first post-quantum standards

A sufficiently capable fault-tolerant quantum computer could apply Shor’s algorithm to factoring and discrete logarithms, threatening RSA and ECC. Symmetric ciphers are not broken in the same way; Grover’s algorithm gives a more general search speedup, leaving larger symmetric keys with margin.

On 13 August 2024 NIST approved:

FIPS 203 / ML-KEM for key establishment;
FIPS 204 / ML-DSA for signatures;
FIPS 205 / SLH-DSA for stateless hash-based signatures.

Migration matters before a public RSA-breaking machine because of “harvest now, decrypt later”: adversaries can retain ciphertext for future decryption. Organisations should inventory algorithms, required confidentiality lifetimes and protocol dependencies. The cryptographic timeline provides a starting point for that programme.

Durable lessons

Do not design custom cryptography. Use maintained libraries and standard protocols.
Authenticate encrypted data. Confidentiality without integrity permits manipulation.
Keys matter more than algorithm labels. Protect generation, storage, access, rotation and destruction.
Build crypto agility. Inventory and migration capability are security controls.
Verify identity, not just encryption. A bad certificate can securely encrypt traffic to an attacker.
Test configuration. A sound primitive in an unsafe mode remains vulnerable.

Cryptography is also part of secrets management and software supply-chain security. Application secrets, KMS keys and signing identities serve different purposes and need separate ownership, access and rotation policy.

Frequently asked questions

Is AES-256 always better than AES-128?

It has more brute-force margin, but both are considered strong when used correctly. Nonces, modes, keys and implementation are more common failure points. Regulation and PQC planning may justify AES-256.

Does TLS hide the website address?

It protects HTTP content and most TLS 1.3 handshake data, but network metadata reveals IP addresses and the hostname may be visible without Encrypted Client Hello. DNS needs separate protection.

Will quantum computers break all encryption?

No. RSA, Diffie–Hellman and ECC face the clearest threat. Symmetric encryption and hashes need adjusted parameters but do not automatically become useless.

Sources

Unsure whether your certificates, mTLS and key lifecycle will survive review? Book a security assessment covering configuration and cryptographic operations.