Why Spies Still Use Shortwave Radio (And What It Tells Us About Modern Encryption)

If you’ve ever stumbled across a shortwave radio broadcast of someone reading out strings of numbers in a flat, robotic voice — congratulations, you’ve found a numbers station. They’ve been running since at least the First World War, intelligence agencies almost certainly operate most of them, and here’s the thing: they’re still broadcasting today.

Why? Because the encryption they use is theoretically unbreakable. Not “hard to break” in the way your Wi-Fi password is hard to break. Genuinely, mathematically, provably unbreakable. The reason has everything to do with a mathematician called Claude Shannon.

Shannon and the One-Time Pad

Shannon was a mathematician and electrical engineer who more or less invented information theory in the late 1940s. Among other things, he formally proved that one type of cipher — the one-time pad — is perfectly secure, provided you follow the rules.

A one-time pad works using XOR, which has a particularly elegant property: it only flips a bit if the corresponding bit in the key is set. That sounds simple, but the implication is profound. If your key is truly random and at least as long as your message, then encrypting the message with it produces ciphertext that contains no statistical information about the original. An attacker trying every possible key would recover every possible message — including the correct one — with no way to distinguish it from the noise. The attack tells you nothing.

The rule, though, is absolute: each key bit can only be used once. Reuse any part of the key and the mathematical proof collapses. The security evaporates. This is why they’re called one-time pads.

The Problem Nobody Talks About

Here’s the catch that makes this impractical for almost everyone: if you want to encrypt a 1 MB message, you need a 1 MB key. To send a gigabyte, you need a gigabyte of key material. That key material must be truly random, pre-shared with your counterpart, kept perfectly secret, and never reused.

This is where the spy tradecraft comes in. Numbers station operators pre-share key material via physical means — the classic dead-drop, a diplomatic pouch, a face-to-face handoff. The agent in the field has a pad of one-time keys; the numbers station uses the same pad to encrypt the broadcast. Once the key material runs out, you need another handoff.

The CIA can afford to do that. Your web application cannot. You can’t ask every visitor to your site to first meet you in a car park in Vienna.

This is the key distribution problem: how do you establish a shared secret with someone you’ve never met, over a channel that may be monitored? For decades, nobody had a good answer. Then, in the 1970s, a few people independently figured it out.

Asymmetric Cryptography: The Clever Bit

RSA, ECC, and DHE are all variations on the same idea: asymmetric key pairs. You generate two mathematically related keys. What one encrypts, only the other can decrypt. You make one public — hand it out freely, post it on your website — and keep the other private.

Anyone who wants to send you something secret encrypts it with your public key. Only you, with your private key, can read it. An observer watching the entire exchange, who even has your public key, cannot decrypt it. The maths involved (factoring very large numbers for RSA, or discrete logarithm problems for ECC/DHE) are computationally infeasible to reverse with current hardware.

This solves the key distribution problem. Two strangers on an untrusted network can now negotiate a shared secret in the open without ever having met.

The downside: asymmetric cryptography is computationally expensive and impractical for encrypting large amounts of data directly. So in practice, it’s used for exactly one thing: bootstrapping a session key.

Symmetric Keys for the Heavy Lifting

Once both parties have negotiated a shared session key via asymmetric methods, they switch to symmetric encryption — typically AES — for the actual data. Symmetric means the same key encrypts and decrypts, and it’s fast. Orders of magnitude faster than RSA.

The asymmetric step protects the symmetric key in transit; the symmetric step handles everything else. Each layer does what it’s good at.

What This Looks Like in Practice: Cipher Suites

When you see something like this in a TLS configuration:

TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256

Each string is a cipher suite — a full specification of every algorithm involved in the connection. Breaking down the first one:

TLS — the protocolAES_128 — 128-bit AES for bulk encryptionGCM (Galois/Counter Mode) — a mode of operation that handles something subtle: it ensures you never encrypt two packets with the same keystream, which would be catastrophic. It also adds authentication, so you can detect tampering.SHA256 — the hash algorithm used for integrity checking

The cipher suite is effectively the recipe card for the entire secure connection.

Perfect Forward Secrecy

Some cipher suites give you a particularly valuable property called perfect forward secrecy (PFS).

Here’s the threat model: a well-resourced attacker records all your encrypted traffic today, with the expectation that they’ll be able to decrypt it later — either by stealing your private keys or by waiting for hardware to catch up. This is a real attack. Bulk traffic collection followed by retrospective decryption is not theoretical.

PFS defeats this by using ephemeral keys during the handshake. The session key is derived from a temporary secret that’s negotiated fresh each session and never stored. Even if an attacker later obtains both parties’ long-term private keys, they can’t reconstruct the ephemeral secret, and therefore can’t decrypt past sessions. What’s gone is gone.

DHE (Diffie-Hellman Ephemeral) and ECDHE (the elliptic-curve variant) are what provide this property in practice. If you see those in your cipher suite, you have PFS.

Key Management: The Bit That Actually Bites You

One thing this article hasn’t really covered, and deserves its own piece: key management. How do you store keys? How do you rotate them? How do you revoke them when something goes wrong? How do you distribute them to a fleet of services without exposing them?

The history of real-world cryptographic failures is less about broken algorithms and more about keys stored in plaintext config files, never rotated, checked into git repositories, or protected by a single point of failure. The maths is the easy part.

Don’t Roll Your Own

Which brings us to the single most important practical point: don’t implement any of this yourself.

The concepts are not that complex. The implementation is a minefield. A single subtle mistake — a nonce reused due to a threading bug, a timing side-channel in a comparison function, a padding scheme implemented slightly wrong — can unravel mathematically sound cryptography entirely. WEP, the original Wi-Fi encryption standard, was broken largely because of IV reuse in RC4. Telegram’s original MTProto protocol had multiple implementation issues that wouldn’t have existed had they used standard primitives. These are not cases of bad intentions; they’re cases of smart people getting details wrong.

Use well-audited, peer-reviewed libraries. In Python, that means cryptography (the package, not the concept). In TLS, that means letting your library negotiate cipher suites rather than configuring them manually unless you genuinely know what you’re doing.

The algorithm is almost never the weakest link. The implementation, the key management, and the human factors almost always are.

Technically you could but conversion rates would be terrible, and it would push up costs for your Vienna office.