Cryptosystems

What a Cryptosystem Is

Everything in this topic is an application of machinery we have already built; nothing genuinely new gets defined. The situation is this: a sender wants to get a message to a receiver over a channel that a third party can listen in on, and wants that third party to learn nothing. The fix is to scramble the message before it goes out and unscramble it at the other end.

Note

Definition
A cryptosystem is a pair of functions: an encryption function which the sender applies to a message to make it unintelligible in transit, and a decryption function which the receiver applies to the received message to recover the original.

Basically, encryption and decryption are inverse functions, and the whole game is arranging things so that the encryption function is easy to apply, easy to invert if you hold one extra piece of information, and hopeless to invert if you do not. The message before encryption is called the plaintext and the message after encryption is the ciphertext.

Two ideas run through this entire lecture. The first is that letters have to be turned into numbers before any arithmetic can happen, and the choice of letter-to-number dictionary matters. The second is that "hard to invert" always ends up meaning some specific computational problem is believed to be slow — factorising for RSA, discrete logarithms for Diffie-Hellman.

The Caesar Shift

The classic toy cryptosystem is the Caesar shift cypher: shift every letter of the message forward some fixed number of positions in the alphabet, wrapping back around to once you pass . For example, the letters of shifted four places down the alphabet become .

To do this arithmetically, the encryption function is built in two steps. First we map each letter to a number giving its position in the alphabet, then we shift the numbers modulo :

where is a fixed secret integer. The decryption function reverses both steps in the opposite order,

The letter-to-number dictionary is the usual one, with one quirk. The natural choice is , , all the way to ; but we are working in , and there. So the dictionary we actually use is:

Letter
Number
Letter
Number

In the Caesar shift, must be sent to , not ; and going backwards, a decrypts to , never to "the zeroth letter". This is purely an artefact of reducing mod and is the single most common slip in these questions. It does not cause any trouble because , so the arithmetic is identical either way; it is only the final translation back to letters that needs care.

Example. Encrypt the message using a Caesar shift with .
Converting to numbers with the table above, , , and (twice). Applying ,

giving the numbers , which translate back to , , , . Therefore, the ciphertext is . As a sanity check by hand, counting three letters forward from gives ; so , exactly as the arithmetic said.

Example. The message was encrypted with a Caesar shift of . Decrypt it.
Converting to numbers gives , and we apply :

Now , , and twice. Therefore, the plaintext is ; notice how the has to be read as on the way back, which is the same quirk seen from the other side.

The Caesar shift is a genuine cryptosystem, but a hopeless one. There are only possible values of , and one of them () does nothing, so an attacker simply tries all non-trivial shifts and reads whichever output is English. A cryptosystem whose key space is small enough to enumerate is worthless no matter how clever the operation is. What we want is a system where the operation is still cheap to compute but the key space is astronomically large, and that is exactly what happens if we replace "add a secret number" with "raise to a secret power".

The RSA Cryptosystem

The upgrade from Caesar is to work modulo a large and encrypt by rather than . The resulting system is the Rivest–Shamir–Adleman, or RSA, cryptosystem, and it is the system that makes public-key cryptography possible: the sender can publish everything needed to encrypt without giving away how to decrypt.

Note

Definition (RSA)
Set-up. Choose two very large primes and , and calculate . Also select an integer that is coprime with .

  • Public information: the modulus and the encryption exponent .
  • Private information: the primes and (and the decryption exponent ).

Encryption. The message is converted in some standard way to a number, or a sequence of numbers, each less than . The sender then encrypts these numbers under the encryption function

Decryption. So long as the receiver knows either or , they can find , and then find with (for example via the EEA). The decryption function is then

Basically, and are shouted from the rooftops so that anybody can send you an encrypted message, while the factorisation is kept secret; and knowing the factorisation is exactly what lets you compute , which in turn is exactly what lets you compute . Everyone can lock the box, only you can open it.

A few points about the set-up that are easy to skip past:

  • We need precisely so that is a unit in and the decryption exponent exists at all. If is not coprime to there is no whatsoever, and the "cryptosystem" cannot be decrypted by anybody, including the intended receiver.
  • Because with distinct primes, is multiplicative on coprime arguments and , so . This is , not ; writing instead of wrecks everything downstream.
  • The plaintext numbers must be smaller than , otherwise two different messages could reduce to the same element of and decryption would be ambiguous.
  • Finding the two large primes in the first place is done with the tests in Primality Tests; you never need to factorise anything to set up RSA, only to break it.

Why RSA Decryption Works

The claim we need is that raising to the power and then to the power gets you back where you started. The source slides justify this in one line with Euler's Theorem, and that line is correct for units; but the messages we actually encrypt are arbitrary numbers less than , and some of them will not be units. It is worth doing this properly.

Note

Theorem (RSA decryption)
Let be primes, let , and let satisfy . Then for every , whether or not is a unit,

Proof. Since and , we may write for some integer , where .

First suppose . Then Euler's Theorem from Fermats Little Theorem and Eulers Theorem gives in , so

which is the easy case. Now drop the assumption and work modulo and modulo separately. Modulo there are two possibilities:

  • If , then , and since we get .
  • If , then Fermat's Little Theorem gives ; and , so writing ,

Either way , and the identical argument with in place of gives . So and ; since and are distinct primes they are coprime, so divides as well (this is the coprime-divisibility argument behind Simultaneous Congruences and the CRT). Hence for every integer .

Basically, splitting into the two prime factors rescues the non-units: an that is divisible by is mod and stays forever, which is exactly what we wanted anyway, and it is still a unit mod so Fermat handles that half. Do not let anyone tell you RSA "only works on units"; it works on every , and we will see a message below whose letters and are genuinely not units mod .

The statement the slides give, , is the unit version of the same fact, and is the reason the exponents live modulo rather than modulo . Reduce exponents modulo ; reduce bases modulo . Mixing these two up is the most expensive mistake available in this topic.

Finding the Decryption Function

Everything in the previous section reduces the practical problem to one line: invert modulo . That is a job for the extended Euclidean algorithm from Bezouts Identity and the Extended Euclidean Algorithm. The working method is:

  • Factorise the public modulus as .
  • Compute .
  • Check ; if not, the system is broken and there is nothing to find.
  • Run the EEA on and to write ; then .
  • If came out negative, add until it lands in .
  • The decryption function is .

Example. An RSA cryptosystem uses the encryption function . Find the decryption function.
The modulus factorises as , so and , and

Since and share no prime factors, and the decryption exponent exists. Running the Euclidean algorithm on and ,

so as expected. Back-substituting to get Bézout coefficients,

Reducing this modulo kills the term and leaves , so . Therefore, the decryption function is

As a check, , so indeed . Always run this one-line check on your ; it costs one multiplication and catches sign errors from the back-substitution instantly.

Example. Find the decryption function for the RSA encryption function .
Here (both prime), so

and since . The Euclidean algorithm gives

and back-substituting,

So , and since we want a positive exponent we take

Therefore, the decryption function is ; checking, , as required. Notice how the EEA gave a negative coefficient here and a positive one in the previous example; the sign is not something you can predict, so always finish by normalising into the range .

Example. Find the decryption function for the RSA encryption function .
Here , so and ; this one is small enough to spot by inspection, since . Therefore and the decryption function is — the same function as encryption. This happens whenever , and is a reminder that a small modulus gives a rubbish cryptosystem; here anybody who can encrypt can also decrypt.

Decrypting a Full Message

With the decryption exponent in hand, decrypting is just a pile of modular exponentiations followed by a translation back to letters. For RSA the letters are usually numbered , , up to , with no wrap-around quirk, because the modulus is bigger than and is a perfectly good element of .

Example. An encrypted message using the cryptosystem is . Decrypt this message.
From the previous section the decryption function is . The message only uses seven distinct ciphertext values, namely and , so we cube each of those once, working in and using to keep the numbers small:

Ciphertext Working in Plaintext Letter
, then
, then
, so

Now substitute back into the message in order:

Position
Ciphertext
Plaintext
Letter

Therefore, the decrypted message is , i.e. "the maid did it". As a check on the whole system, encrypting the first letter again should return the ciphertext: , and since , we get , , , which is exactly the ciphertext we started from.

That last check is worth pausing on. Note that and , so the plaintext letters and are not units in ; Euler's Theorem says nothing at all about them, and yet they encrypt and decrypt perfectly. That is the general decryption theorem doing its job, and it is why we bothered proving the non-unit case.

Example. Decrypt the message , given that the encryption function was .
First find . We have , so , and . The Euclidean algorithm gives and , so

giving (and indeed ). Now compute in for each ciphertext value by repeated squaring, writing :

So the plaintext numbers are , which read as . Therefore, the message is . Notice how replacing by and reducing to before multiplying kept every intermediate number small; reduce after every single multiplication, never at the end.

Why RSA Is Secure

An attacker sees the ciphertext, the modulus and the exponent . To decrypt they need , to get they need , and to get they need the factorisation . So the security of RSA rests entirely on the following claim:

Note

Fact
The security of the RSA cryptosystem relies on the difficulty of factorising a very large number into two very large primes.

Multiplying two -bit primes together takes essentially no time; recovering them from the product is, as far as anybody knows, completely infeasible. That gap is the asymmetry the whole system is built on, and it is genuinely remarkable that it exists, since the operation and its inverse look equally innocent written down.

It is worth noticing how thin the margin is. Knowing either prime is enough, since and then falls out. Knowing is also enough without ever naming the primes, because gives you , and with known you can solve the resulting quadratic. So is every bit as secret as and ; never publish it, and never let a question trick you into thinking it is public information. If and are chosen badly — too close together, too small, or of a guessable special shape — the system falls apart even though is enormous.

The Diffie-Hellman Key Exchange

RSA solves one problem, but plenty of cryptosystems need the sender and receiver to share a secret key beforehand — and if they have never met, there is no obvious way to agree on one over a channel that is being listened to. The Diffie-Hellman(-Merkle) system solves exactly this: two people who have exchanged nothing private can end up holding a common secret number.

Note

Definition (Diffie-Hellman)
Set-up. Persons and choose a very large prime and a (usually large) primitive element . Person chooses some integer as their secret key, and Person chooses some integer as their secret key.

  • Public information: the prime and the primitive element .
  • Private information: the secret keys and .

Encryption. Person computes and announces it. Person computes and announces it.
Conversion. Person computes and Person computes .

The reason this works is one line of index laws:

so both parties end up holding the same number . Basically, exponentiation commutes, so it does not matter in which order the two secret exponents are applied; and arrive at the same place along different routes, and neither ever transmitted their own exponent. Nobody listening in ever sees or — only , , and — and can then be used as the key for whatever symmetric cypher they like.

The shared secret is , not and not . Multiplying the two announced numbers together gives , which an eavesdropper can compute for free; a surprising number of students write this down.

Recall from Order and Primitive Elements that a primitive element of has , and that its powers sweep out the whole of . Two consequences matter here: exponents are only ever meaningful modulo , and every possible element of is a candidate value of . Reduce Diffie-Hellman exponents modulo , never modulo .

Cracking Diffie-Hellman by Brute Force

With small numbers you can attack the system directly, by tabulating the powers of until you find the announced value. That is a discrete logarithm computation, and doing one by hand is the best way to see why the real system uses gigantic primes.

Example. Ada and Byron have set up a Diffie-Hellman cryptosystem with modulus and primitive element . Ada announces that her encrypted number is , and Byron announces that his is . Find their shared secret key.
We need with or with in ; either one on its own is enough, because once we know one secret exponent we can apply it to the other person's announced number. So tabulate the powers of modulo , reducing at every step:

Byron's number appears almost immediately: , so Byron's secret key is . That is all we need. Applying it to Ada's announced number, and writing in ,

Therefore, the shared secret key is .

For completeness, let us also find Ada's key by continuing the table until shows up:

So and Ada's secret key is . Notice the landmark at : since is primitive and , we must have , and the table confirms it. That single fact halves the work, because ; for instance immediately gives

without tabulating anything past . Cross-checking the shared key three different ways,

where the last line reduced the exponent modulo the order and then read straight off the table. All three agree, which is a strong sign that the two discrete logarithms were read correctly.

Example. You and a friend have set up a Diffie-Hellman cryptosystem with modulus and primitive element . Your friend announces that their encrypted number is . Find their secret key.
Tabulate the powers of in :

Reading along, . Therefore, your friend's secret key is . (Strictly, any exponent congruent to modulo would produce the same announced number, so the key is only determined modulo ; the smallest positive choice is .)

Why the Base Must Be Primitive

The last two examples show the whole system being broken by hand in under a minute, which is precisely what a real Diffie-Hellman set-up is trying to make impossible. The defence is to make enormous, and — crucially — to insist that is a primitive element.

The reason is that a brute-force attacker only ever has to search through the set of numbers that are actually reachable as powers of , namely . If is primitive then , which has elements and is as large as the search space can possibly be. If is not primitive, then is a proper divisor of , so it is at most ; choosing a non-primitive base instantly halves (at best) the number of possibilities an attacker has to check, and usually does far worse than that.

The extreme case makes the point vividly. Suppose someone chose . Then

so the only numbers that can ever be announced are and , the shared secret is one of two values, and an attacker guesses it on the first or second try. All the size of has bought you is nothing at all; the security came from the order of the base, not the size of the modulus. This is the same lesson as the -key Caesar shift, dressed up differently.

Note

Fact
The security of the Diffie-Hellman cryptosystem relies on the difficulty of calculating discrete logarithms, that is, of finding given , and .

Basically, computing by repeated squaring is fast even when has hundreds of digits, while going backwards from to has no known fast method for a general large prime . That one-way behaviour is the entire foundation, and it is a different hard problem from the factorising problem that props up RSA; if somebody found a fast factorising algorithm tomorrow, Diffie-Hellman would not automatically fall with it (and vice versa).

Common Exam Traps

Almost every mark lost in this topic comes from one of the following, so it is worth reading this list before an exam.

  • must be coprime to . If then no decryption exponent exists at all. Check the gcd before you start the EEA rather than discovering it halfway through.
  • Exponents live modulo , bases live modulo . Solve , never . In Diffie-Hellman the corresponding modulus for exponents is , never .
  • , not . For this is , not . Every subsequent number is wrong if this one is.
  • Normalise to a positive value. The EEA cheerfully returns things like ; add until lands in , then verify by direct multiplication.
  • Do not reduce the exponent modulo the order of a non-unit. In the system, the plaintexts and are not units mod ; the decryption theorem covers them, but Euler's Theorem applied blindly does not.
  • Get the letter dictionary right. For the Caesar shift, because we work in ; for RSA the standard is through with no wrap. Check which one the question is using before converting anything.
  • In Diffie-Hellman, you only need one of the two secret keys. Once you have found from , apply it to ; there is no need to solve the second discrete logarithm as well, and doing so wastes exam time.
  • The Diffie-Hellman shared secret is . It is not , and it is not .
  • Reduce at every step of a modular exponentiation and use small negative representatives ( mod , mod ); this is the same advice as in Modular Arithmetic and it is what keeps these computations doable by hand.
  • Remember what is public. In the RSA set-up the pair is public and are all secret; in the Diffie-Hellman set-up the pair is public along with the announced , while , and are secret. Questions frequently hinge on noticing that is not public information.

Finally, keep the definition of a cryptosystem in mind as the frame for the whole topic: everything here is a pair of mutually inverse functions, and the interesting content is never the algebra (which is just index laws and Euler's Theorem) but the asymmetry — the gap between how hard the forward map is and how hard the backward map is without the key. That is also what distinguishes this lecture from Codes, where the enemy is random noise rather than an eavesdropper, and where we happily publish everything.