One-Time Pad Generator

Generate one-time pad keys and encrypt with perfect secrecy. Cryptographically random keys, XOR encode and decode, and notes on using a pad safely.

Advertisement

One-time pad encryption: the only cipher with information-theoretic security, and the four conditions that make it real

The one-time pad occupies a unique position in cryptography. Every other cipher in use — AES, ChaCha20, RSA, elliptic curve — is computationally secure: breaking it is possible in principle and merely infeasible with the computers and mathematics we have. The one-time pad is information-theoretically secure. Given the ciphertext and unlimited computing power and unlimited time, an attacker still cannot recover the message, because the ciphertext genuinely does not contain it. Claude Shannon proved this in 1949, and no amount of future hardware, quantum or otherwise, changes it.

That claim holds only under four conditions, all of which must be true simultaneously. Break any one and the guarantee does not weaken gradually — it collapses. Most of this page is about those conditions, because that is where the actual engineering lives.

Using this tool

The mechanism is XOR, byte by byte, message against key. To encrypt, type your message, press Generate to produce a random key exactly as long as it, and read the ciphertext. To decrypt, supply the same key and the same ciphertext.

FieldFormatNotes
MessagePlain textCharacter count is shown live and drives the required key length
KeyHexadecimal onlyNon-hex characters are stripped as you type; the byte count is shown
OutputHex, binary or textHex is the default and the only one that survives copy-paste reliably

Type ATTACK AT DAWN — 14 characters — and Generate produces 14 random bytes, which is 28 hexadecimal digits. The tool refuses to produce output if the key is shorter than the message, and tells you by how much, because a short key is the single most common way people accidentally turn a one-time pad into a repeating XOR cipher.

Everything happens in your browser. There is no upload, no server round trip and no logging — the message, the key and the ciphertext exist only in the page. That is not a nicety here; a one-time pad you generated on someone else's server is not a one-time pad.

Why it is unbreakable — a worked example

Take the two-byte message HI, which in ASCII is 48 49, and the random key 3f a2. XOR them:

Byte 1Byte 2
Plaintext HI48 = 0100 100049 = 0100 1001
Key3f = 0011 1111a2 = 1010 0010
Ciphertext77 = 0111 0111eb = 1110 1011

Now the crucial part. Suppose an attacker has 77 eb and guesses the message was NO (4e 4f). Is that consistent? XOR the ciphertext against that guess to get the key it would require: 77 ⊕ 4e = 39, and eb ⊕ 4f = a4. Key 39 a4. That is a perfectly valid two-byte key — nothing about it is malformed, unlikely or detectable. The guess is entirely consistent with the ciphertext.

So is every other two-byte message. GO, NO, OK,  — each one corresponds to exactly one key, and since the real key was drawn uniformly at random, every one of those keys was equally likely. The ciphertext is consistent with all 65,536 possible two-byte plaintexts, with no way to prefer any of them. That is what "the ciphertext does not contain the message" means, and it is why the attacker's computing power is irrelevant: there is nothing to compute toward.

Contrast this with AES. An AES ciphertext is consistent with exactly one plaintext under exactly one key; brute-forcing the key would find it, and the security claim is only that you cannot afford to. A one-time-pad ciphertext is consistent with all of them. Different kind of statement entirely.

One thing it does not hide: length. The ciphertext is exactly as long as the message, so the size of what you sent is visible. Real systems pad messages to fixed sizes to deal with that.

The four conditions

ConditionWhat goes wrong if it fails
Key at least as long as the messageThe key must repeat, and the cipher degrades into a repeating-key XOR, which is broken by frequency analysis on each key-length-spaced column
Key truly randomThe key becomes predictable from its own output; recovering the generator's state recovers the whole keystream
Key used exactly onceTwo ciphertexts under one key leak both plaintexts — see below
Key kept secret and destroyedThe cipher is trivially reversible by anyone with the key, and a retained key makes past traffic decryptable later

Notice the second condition says truly random, not "cryptographically random". This tool generates keys with the browser's crypto.getRandomValues, which is a cryptographically secure pseudorandom generator seeded from the operating system's entropy pool. That is the right choice for a browser and it is far stronger than Math.random — but it is still a deterministic algorithm expanding a finite seed. The output is computationally indistinguishable from random, which makes the resulting cipher computationally secure, not information-theoretically secure. A genuine one-time pad needs a physical entropy source: radioactive decay, thermal noise, a hardware RNG. Historical pads were literally printed from such sources onto paper and destroyed after use. This is worth being blunt about, because a great deal of one-time-pad software quietly elides it.

The two-time pad: what reuse actually leaks

This is the failure that has sunk real systems, and the mechanism is one line of algebra. Encrypt two messages with the same key k:

c₁ = m₁ ⊕ k and c₂ = m₂ ⊕ k

An attacker who has both ciphertexts XORs them together. The key appears twice and cancels, because k ⊕ k = 0:

c₁ ⊕ c₂ = m₁ ⊕ k ⊕ m₂ ⊕ k = m₁ ⊕ m₂

The key is gone entirely, and what remains is the XOR of the two plaintexts — with no key involved at all. Using the numbers from above: HI and NO under key 3f a2 give 77 eb and 71 ed. XOR those two ciphertexts and you get 06 06. XOR the two plaintexts directly and you also get 06 06. The key never mattered.

From m₁ ⊕ m₂, both messages fall out with paper and patience, by a technique called crib dragging. Guess a likely word — " the ", a header, a name — XOR it in at each offset, and look at what comes out at the corresponding position in the other message. Nonsense means the guess is wrong there; readable English means you have found a fragment of both messages at once, which gives you a longer crib to drag next. Natural language is redundant enough that this converges quickly, and it converges on both messages simultaneously.

The historical case is VENONA. Soviet diplomatic and intelligence traffic used one-time pads correctly in principle, but wartime production pressure led to some pad pages being duplicated and issued twice. US codebreakers, starting in 1943, found the overlaps and read the affected messages — a programme that ran for decades. The cipher was not broken. The key management was. That is the recurring lesson: the one-time pad has no cryptanalytic weakness to attack, so every real-world break has been a key-handling failure.

Two practical corollaries. First, "one time" means one time for that key material across all directions and all correspondents — if A encrypts to B with a pad and B encrypts a reply with the same pad, that is reuse. Systems solve it by splitting the pad into a sending half and a receiving half. Second, appending to a message and re-sending it under the same pad is reuse of the overlapping prefix, and leaks it.

Why nobody uses it for ordinary traffic

The key must be as long as the message, so encrypting a gigabyte requires a gigabyte of key. And that key has to reach the recipient over a channel that is already secure — if you had such a channel, you could have sent the message over it. This is the circularity that makes the one-time pad impractical for general communication, and it is exactly the problem that public-key cryptography was invented to solve: Diffie–Hellman and RSA let two parties agree on a short key over an insecure channel, and a modern cipher stretches that short key into as much keystream as needed. That stretching is precisely what a one-time pad refuses to do, and it is also precisely why modern ciphers are only computationally secure.

Where the trade does make sense: a small number of very high-value messages between parties who can meet physically in advance. Diplomatic couriers carrying pad material, the Washington–Moscow hotline, numbers stations broadcasting to agents with a printed pad. In every case the key travelled by hand, once, ahead of time, and the messages were short.

The one modern relative worth knowing is quantum key distribution, which uses quantum mechanics to establish shared random key material with eavesdropping detectable in the channel itself. Combine QKD with a one-time pad and you get the theoretical guarantee end to end — at the cost of dedicated optical fibre, which is why it is rare.

Honest limits of this implementation

  • Encrypt and Decrypt do the same thing. XOR is its own inverse, so the two modes change only the field labels. Applying the same key to the ciphertext returns the plaintext; there is no separate decryption routine because none is needed.
  • The message box is always read as text. It is not a hex parser. If you encrypt, get hex output, then paste that hex back in to decrypt, you will be XORing the hex digits as characters, not the bytes they represent, and the result will be wrong. This is a demonstrator for the mechanics rather than a round-trip messaging client.
  • Key length is counted in characters, not UTF-8 bytes. For plain ASCII the two are identical and everything is correct. For text containing accented Latin, CJK or emoji, one character can be two to four bytes, so a generated key will be short and the trailing bytes will pass through unprotected. Stick to ASCII, or supply a longer key by hand.
  • Nothing is stored. Closing the tab loses the key. If you generated a key you intend to use, copy it somewhere first — and note that "somewhere" is now the weakest part of your system.

Questions

  • Is a one-time pad quantum-resistant? Yes, and uniquely so. Shor's algorithm attacks the structure of RSA and elliptic curve; Grover's halves the effective key length of symmetric ciphers. Neither touches a cipher whose ciphertext contains no information about the plaintext to begin with.
  • Can I use a passphrase as the key? No. A passphrase is short, non-random and low-entropy. Using one turns this into a repeating-key XOR cipher, which is a classical exercise to break, not a secure system.
  • Can I reuse a pad if the two messages are completely unrelated? No. The attack does not care what the messages say; it removes the key by algebra alone and then exploits the redundancy of language.
  • Why hex for the key? Because the key is random bytes, and most byte values are not printable characters. Hex is the standard lossless way to write arbitrary bytes as text.
  • Should I use this to protect real data? No. Use an authenticated cipher — AES-GCM or ChaCha20-Poly1305 — which also detects tampering. A one-time pad provides confidentiality but no integrity: flipping a bit in the ciphertext flips exactly the corresponding bit in the plaintext, undetected, which is a well-known malleability problem.

If you want to experiment with the underlying operation on arbitrary key lengths rather than the strict pad discipline, the XOR Cipher tool covers that case.

This tool is provided for informational and educational purposes only. All processing happens in your browser — no data is sent to or stored on our servers. While we strive for accuracy, we make no warranties about the completeness or reliability of results.