Use repeating-key XOR for learning, not security

Problem

XOR is often introduced with the convenient identity that applying the same key twice restores the original bytes. That identity is correct, but classroom notes and small web tools frequently hide important details: text must first become bytes through an encoding such as UTF-8; a multi-byte key repeats over those bytes rather than visible characters; Hex and Base64 are only representations of the result; a different key or format cannot reliably recover the source; and a short repeating key leaks structure while providing no authentication. A successful round trip can therefore look much more secure than it is. This guide uses one bounded, exact example to separate the reversible operation from its byte representation and from real authenticated encryption. Keep every input disposable. The purpose is to understand mechanics, debug a puzzle, or document a known vector, not to protect a password, token, private message, customer record, or file.

When to use this

• You are learning why XOR is self-reversing when the identical byte key is applied twice.
• A classroom exercise or CTF puzzle provides a known repeating key and an exact Hex or Base64 payload.
• You need to verify a small UTF-8 XOR test vector across two implementations without using production data.
• You are explaining the difference between reversible cipher operations, byte encodings, hashes, and modern authenticated encryption.

Steps

1. Step 1

   Choose a disposable known example

   Open XOR in the Cipher Learning Workbench and select Encode. Use the plaintext hello world and the learning key demo. Do not paste a real password, API key, token, customer value, or private message merely because the transform runs locally.

2. Step 2

   Select the exact byte representation

   Choose Hex first. The workbench converts both plaintext and key to UTF-8 bytes, repeats the key bytes over the input, applies XOR byte by byte, and renders every result byte as two hexadecimal characters.

3. Step 3

   Verify the known Hex vector

   Run the transform and compare the complete result with 0c0001030b451a00160909. One changed nibble means the input, key, text encoding, repetition rule, or output formatting differs, so stop and resolve that mismatch before decoding.

4. Step 4

   Reverse with the same key and format

   Use the result-as-input action to switch to Decode while retaining Hex and the key demo. The strict decoder accepts an even number of Hex characters without spaces or prefixes, applies the same XOR bytes, requires valid visible UTF-8, and should recover hello world exactly.

5. Step 5

   Repeat with canonical Base64

   Return to Encode, select Base64, and run the same plaintext and key. The exact padded standard Base64 result is DAABAwtFGgAWCQk=. Decode with Base64 selected; an unpadded value, whitespace, Base64URL alphabet, or Data URI is rejected rather than silently normalized.

6. Step 6

   Record the security boundary

   Document the plaintext encoding, key bytes, repetition rule, Hex or Base64 format, and expected vector. Also state that repeating-key XOR has no nonce management, authentication tag, tamper detection, secure key lifecycle, or resistance to pattern analysis and must not protect real data.

Example

Direction: Encode
Key: demo
Plaintext: hello world
Format: Hex

Hex: 0c0001030b451a00160909
Base64 representation of the same bytes: DAABAwtFGgAWCQk=
Decode either representation with key demo to recover: hello world

Common mistakes

FAQ