Remark11.5.1
Sage note:
Remember, this cell contains the commands used to make numbers from letters, so always evaluate it before doing any en/decoding.
Sage note:
Remember, this cell contains the commands used to make numbers from letters, so always evaluate it before doing any en/decoding.
In order to deal with all these issues, we will now introduce the most famous public-key system. Recall that this is one where we want an encryption key that is easy for anybody at all to use, but is very difficult to undo unless you know the secret. (Sometimes this is called a trapdoor system, because it's easy to fall in but it's hard to get back out unless you know where the secret passageway is!)
The formal name is “Rivest, Shamir, Adleman”, for the three folks who developed it in the late 1970s. The acronym continues to be the name of the security company they cofounded, now owned by EMC.
The idea is to make Diffie-Hellman, which technically only relies upon Fermat's Little Theorem and primes, into a system which involves Euler's Theorem, but not so heavily as to make the computation too expensive. It turns out that the easiest way to do that is to choose a large integer \(n\) with only two prime factors, instead of one large prime \(p\) as we did before. For instance:
Now, exponents here live in the world of \(\phi(n)\). We can easily compute this using our magical formula (so that \(\phi(n)=(p-1)(q-1)\)). So the computations are going to be easy for us.
But they will not be so easy to compute without our magical formula, and to use our magical formula we need to have the prime decomposition of \(n\).
In particular, for reasonably large \(n\), that means \(\phi(n)\) is essentially secret to anyone who isn't tough enough to factor \(n\). As an example, in the early 1600s, Fermat believed \(2^{32}+1\) was prime. It took until 1732 and the genius of Euler to factor \(2^{32}+1\) as follows:
Hence \(n=2^{32}+1\) wouldn't have been a bad \(n\) to choose in the early 1700s, since it would take a LOT of the sieve of Eratosthenes to get to the one hundred sixteenth prime!
That's the preliminaries. From now on, we do exactly the same thing as before, choosing an \(e\) coprime to \(\phi(n)\), etc. This time, though, instead of keeping \(e\) secret, we let anybody know it (along with \(n\), which we have to let people know anyway).
With the same primes, let's choose \(e=71\), because that is coprime to \(\phi(89\cdot 97)=\phi(89)\phi(97)=88\cdot 96=8448\).
And now we compute an inverse mod \(\phi(n)\) just as before, which will be (as before) our decryption key. Since we are able to compute \(\phi(n)\), it isn't hard to get an inverse for \(e\); if you only knew \(n\), though, it would be very hard to do this.
Now, just like with D-H, I raise my message (number) to the power \(e\) to encrypt, and raise to the power \(f\) to decrypt an encrypted message. Here are all the steps together!
Now we have an encryption method where anyone can encrypt. The modulus \(n\) (not written as \(pq\)) and \(e\) are both published, and anyone who wants to send a message of length \(n\) or less just exponentiates. You just have to be sure that \(\phi(n)\) and \(e\) are coprime for it to be defined properly.
In order to encrypt a message \(x\) via RSA with public key \((n,e)\), you do \[x^e\text{ mod }(n)\; ;\] in order for the owner of the key to decrypt a message \(m\), they do \[m^{e^{-1}}=m^f\text{ mod }(n)\; .\] Since \[ef\equiv 1\text{ mod }(\phi(n))\; ,\] \(ef=k\phi(n)+1\) for some integer \(k\). Hence \[(x^e)^f=x^{ef}=x^{k\phi(n)+1}=(x^{\phi(n)})^k x^1\equiv 1^k x\equiv x\text{ mod }(n)\] and it all works out, we recover the original message.
And if someone nefarious were to try to decrypt this, they would need access to \(f\) somehow, or something equivalent to it mathematically. That would mean solving \[ef\equiv 1\text{ mod}(\phi(n))\] for \(f\) without actually knowing what \(\phi(n)\) is!
Naturally, that is pretty easy to compute in the cases above. But in real life?
The \(n\) in the cell above is the product of two primes - but would you like to try to compute \(\phi(n)\) by hand? Without knowing the actual primes, it could be very difficult to figure out \(\phi(n)\), which you probably need to get \(f\).
Realistic examples have much larger primes than this, say 100 digits. But let's see what would happen next in a 'real' example.
Hopefully the randomness of the \(p\) and \(q\) I picked didn't keep \(n\) from being greater than the numerical value of the message.
Now we pick the other piece of our key, \(e\). Believe it or not, it doesn't really seem to matter (though no one has proved this) what \(e\) is; documentation for this widely used RSA implementation says “The modulus size will be num bits, and the public exponent will be e. Key sizes with num < 1024 should be considered insecure. The exponent is an odd number, typically 3, 17 or 65537.”
Well, I figure \(17\) is easier to use than \(65537\) but less obvious than \(3\). Let's check that it's coprime to the modulus of the key.
If you get False above (I did once in a while during testing), then just pick a different \(e\). (Only evaluate this cell if you have to!)
Once we have our key, away we go!
Crack that! Who knows what \(\phi(n)\) is?
But if I know it, I can calculate the inverse of \(e\):