009 | Gilbert Vernam’s paper tapes

“When cryptography learns to type for itself”

His artefact is not a gleaming machine like Enigma, but a patent and a habit: punched paper tapes, running side by side, with bits being combined in a way we would call XOR but he did not. Hardly surprising since the term was not in use until the 1960s. In 1917 he proposed “a teleprinter cipher in which a previously prepared key, kept on paper tape, is combined character by character with the plaintext message to produce the ciphertext.”

That sounds almost boring until you realise that this is the moment cryptography stops being something humans do to messages and becomes something machines do for other machines. Vernam’s cipher² is an early stream cipher: a keystream and a message stream, combined mechanically, at line speed. It is the ancestor of every modern stream cipher and of the way we now casually secure billions of machine‑to‑machine conversations a day.

By the 1910s, electrical communication is no longer a novelty. Telegraph networks span continents; teleprinters and multiplexed lines are turning messages into a continuous industrial flow. Human clerks can no longer hand‑encrypt every message with a codebook or a pencil cipher without becoming the bottleneck. The system wants automation. Vernam’s answer is to treat both message and key as signals rather than as letters. Teleprinter characters are encoded in Baudot code; each character is a pattern of impulses. Vernam’s patent describes combining those impulses with a second stream of impulses from a key tape, using what we now call XOR.

Exclusive OR (XOR)

In US Patent 1310719³, it is described as a combining function applied bit‑by‑bit to teleprinter impulses. The patent emphasises that there is a distinct conceptual leap: treating encryption as a bitwise electrical operation, not as a substitution table.

The same operation encrypts and decrypts: applying the same keystream again to the output recovers the cleartext.

Teleprinters, tape, and the problem of scale

This is a conceptual shift. The cipher is no longer a clever alphabet table; it is a Boolean function wired into a network. Cryptography becomes part of the infrastructure, not an afterthought. The people behind this are not just Vernam of course. Telegraph operators have to handle the tapes. Engineers have to keep the relays and printers working. Supervisors have to decide when key tapes are issued, how long they are, how they are stored and destroyed. Cryptography is becoming a profession in the sense that it now has workflows, logistics and maintenance, not just cleverness.

When “perfect secrecy” meets logistics.

Shortly after Vernam’s work, Joseph Mauborgne of the US Army Signal Corps suggests a twist: what if the key tape is truly random, as long as the message, and never reused? Combine that with Vernam’s mechanism and you have an automated one‑time pad, decades before Claude Shannon proves why that matters. In theory, this is perfect secrecy. In practice, it is a logistics problem disguised as a cipher. Key tapes must be:

• Generated with real randomness
• Distributed securely to both ends
• Tracked so they are never reused
• Destroyed completely and with high assurance after use – all copies!

Those are not mathematical tasks; they are human and organisational ones. The history of one‑time pads is therefore a history of people under pressure cutting corners.

Project VENONA⁴

This is the most famous example. Soviet intelligence used one‑time pads for diplomatic and espionage traffic. Under wartime supply pressure, some key pages were reused. That single operational failure turned perfect secrecy back into a Vernam‑style depth attack:

> “When key tapes were reused (common under operational pressure), XOR-ing two ciphertexts cancels the key: C1 ⊕ C2 = P1 ⊕ P2… The same depth attack that breaks a reused Vernam tape broke thousands of Soviet intelligence messages.”

The result was decades of decrypted traffic, exposing agents and operations. The cipher was fine. The logistics were not. This is why Vernam belongs in a cybersecurity history rather than just a cryptography museum. It shows that perfect mechanisms still fail when they meet imperfect humans, supply chains and record‑keeping. And those are unavoidable in the real world, however much we might wish otherwise.

—Streams, not blocks: a new mental model

Vernam’s design also changes how we think about encryption. Instead of treating a message as a static object to be transformed, it treats it as a stream to be mixed with another stream. That mental model survives into modern protocols. Every time a browser and a server agree a key and then use AES‑CTR or ChaCha20 to protect a connection, they are doing a Vernam‑style dance: generate a keystream, XOR it with the plaintext, send the result. The difference is that the keystream now comes from a pseudorandom generator seeded with a short key and a nonce, not from a physical tape. But the core idea of bitwise combination of two streams is the same. This matters for cybersecurity because it ties confidentiality to state. Lose track of your counters, nonces or sequence numbers and you risk reusing keystream, just as surely as a harried Soviet cipher clerk reusing a pad page. The modern “never reuse a nonce” warning in stream ciphers is a direct descendant of the “never reuse a key tape” lesson. So Vernam’s artefact is not just a historical curiosity. It is the ancestor of:

• VPN tunnels
• Encrypted messaging protocols
• TLS session protection
• Disk and link encryption modes that treat data as streams

Every time we design a system that must keep track of per‑session state to avoid keystream reuse, we are quietly re‑enacting the same trade‑offs Vernam and Mauborgne faced: simplicity versus safety, convenience versus discipline.

—Machines, professions, and the people in the margins

The octet this artefact sits within is about “Cryptography becomes machinery, intelligence and profession.” Vernam is the machinery part, but he also hints at the profession. Once encryption is built into telegraph networks, someone has to:

– Decide which circuits are protected – Train operators in key handling – Audit usage and investigate anomalies – Integrate cryptography with intelligence requirements

Those roles are early versions of what we would now call security engineering, key management, and signals intelligence analysis. They are not glamorous, and they rarely get their names on patents, but they are the difference between a beautiful design and a secure system. The VENONA story again makes this visible. The Soviet cipher clerks who reused pads were under pressure to move traffic. The American and British analysts who spotted the resulting patterns were doing painstaking, unglamorous work. The intelligence officers who then had to decide how to use that knowledge without revealing the source were wrestling with the same “how do we burn this?” dilemma we saw in the Zimmermann Telegram. A history that only names Vernam and Mauborgne would miss the point. The artefact is the whole system: engineers, operators, clerks, analysts, and the institutional habits that made key reuse either unthinkable or inevitable.

—Lessons that refuse to stay historical

What does Vernam teach a modern security practitioner who has never touched a paper tape?

Firstly, that mechanisation does not remove humans from the loop; it just moves them. We still rely on people to:

– Configure key lifetimes – Rotate certificates – Manage hardware security modules – Decide how much operational pain is acceptable in the name of safety

When those people are rushed, under‑resourced or ignored, we get the modern equivalents of pad reuse: long‑lived keys, shared credentials, hard‑coded secrets, copy‑pasted configuration.

Those who know me may well recall me talking about “Good, well-managed, TLS” as if it were two things, not one. Because it is; good TLS is about ciphersuites & protocol versions. Well-managed TLS is about all those other elements. They should remember me talking about it because I mention it often enough…

Secondly, that perfect secrecy is not the same as practical security. One‑time pads are still theoretically unbreakable, but almost nobody uses them at scale because the logistics are brutal. Instead, we use ciphers that are “good enough” under realistic assumptions, and we pour our effort into key management, protocol design and monitoring. That is not a failure of cryptography; it is an acknowledgement that security is a systems problem.

Thirdly, that statefulness is a security property. Stream ciphers, counters, nonces and sequence numbers all require careful bookkeeping. When that bookkeeping fails, the mathematics collapses. This is why protocol design is hard and why “just encrypt it” is never enough; in many ways that’s the easy part.

—Looking ahead in the octet

Vernam’s paper tapes are the opening move in this octet’s story. After him come the one‑time pad as an ideal, the Zimmermann Telegram as a political intelligence artefact, Enigma as industrialised military cryptography, and the women and men who turned cryptanalysis into a profession rather than a parlour trick. Together, they show cryptography becoming:

– Machinery — electromechanical, then electronic – Intelligence infrastructure — feeding strategy, war and diplomacy – A profession — with training, doctrine, career paths and institutional memory

Vernam sits at the hinge point where ciphers stop being hand tools and start being part of the network itself. That is why he earns his place in this history.

Artefact 009, then, is not just about a patent from 1917. It is about the moment we taught our networks to keep their own secrets, and discovered that the hardest part would always be persuading humans to treat key material as more than just another roll of tape.

References & Links

1. https://en.wikipedia.org/wiki/Gilbert_Vernam ↩︎
2. Includes a working emulation of the Vernam Cipher
   https://ciphermuseum.com/ciphers/vernam.html ↩︎
3. Searchable text of the patent application https://patents.google.com/patent/US1310719A/en
   Scan of the original patent application https://patentimages.storage.googleapis.com/5d/ae/f5/1256151a84830e/US1310719.pdf ↩︎
4. Wikipedia article https://en.wikipedia.org/wiki/Venona_project
   ↩︎