Cryptography: four methods, from Caesar to Alice and Bob

Cryptography transforms a readable message into text that requires a key to interpret. The first three methods can be explored with pencil and paper or a spreadsheet; the fourth introduces two different keys. Try each step in the interactive laboratory. The cover illustrates the passage from letter transformations to public and private keys; it is a conceptual image, not a technical diagram.

1. Substitution: shifting letters

Choose k=2 and use A–Z. Replace each letter by the one two positions later, wrapping around after Z: S→U, A→C, L→N. Thus SALVATORE becomes UCNXCVQTG. To decrypt, move each letter two positions back: U→S, C→A, until SALVATORE returns. This is the principle of the Caesar cipher, but letter frequencies remain visible, so it does not protect real data.

2. Transposition: change the order, not the letters

With key MOSAI and plaintext SALVATORE, write the letters from left to right under five columns:

M O S A I
S A L V A
T O R E

The original columns are ST | AO | LR | VE | A. Reading them in alphabetical key order, A,I,M,O,S, gives VE | A | ST | AO | LR, or VEASTAOLR. Bob knows the same key: he determines each column length, fills the columns in alphabetical order and reads across the rows to recover SALVATORE. This version removes spaces, accents and punctuation before encryption; they cannot be automatically restored.

3. XOR: the same numeric key encrypts and decrypts

Take the ASCII byte for the first letter, S=83, and a one-byte key 113. Bitwise combination yields 83 XOR 113 = 34, or 22 in hexadecimal. Apply the key again and 34 XOR 113 = 83: S reappears. For SALVATORE the complete hexadecimal sequence is 22303D2730253E2334. The laboratory applies XOR to UTF-8 bytes, so it can also process non-ASCII messages. Reusing one key byte is insecure: this only demonstrates (m XOR k) XOR k = m.

4. Public-key cryptography: Alice writes to Bob

In our RSA example, Bob chooses two primes, p=61 and q=53. He computes n=pq=3233 and φ(n)=(p−1)(q−1)=3120. He chooses e=17, coprime to 3120, and finds d=2753, since 17×2753=46801=15×3120+1. He publishes (n,e)=(3233,17) and keeps d=2753 private.

Alice wants to send CIAO. Its UTF-8 bytes are 67,73,65,79. For each byte m she uses Bob’s public key to compute c=m^17 mod 3233:

C: 67^17 mod 3233 = 641
I: 73^17 mod 3233 = 1486
A: 65^17 mod 3233 = 2790
O: 79^17 mod 3233 = 1307

She sends 641 1486 2790 1307. Bob applies his private key to every block: m=c^2753 mod 3233. In order he recovers 67,73,65,79; UTF-8 decoding gives CIAO. Mathematically, e×d≡1 (mod φ(n)). Alice never needed Bob’s private key.

Inside the calculation for one letter

Rather than construct the huge power 65^17, Alice squares and reduces modulo 3233 each time: 65²≡992, 65⁴≡1232, 65⁸≡1547 and 65¹⁶≡789. Since 17=16+1, 65¹⁷≡789×65≡2790 (mod 3233). Bob uses the same method with exponent 2753=2048+512+128+64+1 and recovers 65. This is the concrete encryption and decryption of the letter A.

What this does and does not prove

This example illustrates the difference between a shared key and a public/private pair; it is not usable protection. The primes can be factored by hand, each byte is encrypted separately and there is no padding. For real applications, RFC 8017 specifies RSAES-OAEP: do not copy this elementary RSA into a security system. Also, knowing a public key does not itself prove that it belongs to Bob; its identity must be verified. Open the laboratory and try another message →