This will be a quick primer for public key cryptography in layman terms. I’d like to use the content for a Toastmasters’ speech in the not too distant future, hopefully leading to a Bitcoin presentation.

We often take for granted how easy it is to send messages securely over the internet. From filing taxes to transferring money, “how conveniently can it be done”, as opposed to “how securely can it be done” is the usual question. What does it really mean to be secure over the internet though? What does the green lock you see when you run your browser really mean?

Let’s try and walk through the steps involved in making a bank transfer, and see what could go wrong.

As is the tradition in IT security, we will use the characters Alice and Bob. Alice wants to transfer $100 to Bob. At her terminal, she wants to send a message the equivalent of “transfer $100 from my account to Bob”.

This message has to travel across numerous connections till it finally gets to the bank, where it is read and processed.

How can we prevent anyone else along the way from reading Alice’s message? Apart from buying over all the links to our bank on the internet, one option would be to scramble the message and foil any would-be eavesdroppers. This is known as encryption, and would work, except that Alice’s bank would need to know how to unscramble the message and actually process it.

Encryption is not a new problem, many methods/algorithms exist, but they all rely on a specific “key” that is known beforehand. How would it know beforehand how to get this key? It would also need to make a different one for each account holder, otherwise any customer of the bank could read any other customer’s data.

You can’t really send the key over the internet since that could be intercepted and read. You could go to your bank and negotiate some kind of secret, common key beforehand. That would work, but it wouldn’t be very feasible for all parties you’d like to conduct a transaction with, like say Amazon.

The solution that was eventually adopted used a neat bit of math. Rather than using the same, single “key” that both alice and her bank could decrypt/encrypt with, a type of encryption method exists where each party has two keys. These keys are often called private and public keys, for reasons that will become obvious soon. A message encrypted using the bank’s public key can only be decrypted using bank’s private key, and vice versa. The key thing here is that knowledge of the public key does not allow you to decrypt the message.

In practice, any website that operates over https as opposed to http has generated a pair of keys. Your web browser automatically does the required encryption using the website’s public key. When you visit a https website, the website presents its public key to you and you then use it for encrypted communications.

The more eagle-eyed or technically inclined audience might spot a problem here. Suppose Eve controls one of the computers along the chain. When the initial public key is being sent to Alice, she instead replaces the bank’s public key with one of her own, so that Alice now encrypts her data using Eve’s public key. Eve can now intercept the messages and relay them to the bank, possibly modified to say transfer money to her account.

This can be prevented if we knew beforehand what the bank’s public key actually was, without actually needing the bank to present itself. Some kind of centralised key registry. However, this key registry would need to be dynamic since new websites are registered all the time, and you would need to “know” the public key of this centralised key registry in order to start the whole process in a secure fashion.

In practice, what happens is not so different. A secure website doesnt just present its public key, the public key forms part of a certificate. Just like say a birth certificate, it is meant to certify the identity of the website, so it contains the entity name, organisation etc. The interesting technical part of all this is the certificate is usually certified by a certification authority (remember key repository?). This certification authority in turn is usually certified by yet another certification authority, and so on until we reach a root certification authority. Your browser, when installed, contains files that can be used to verify only these root certification authorities. This is known as a certificate chain, one end of the chain is the website you are visiting, and on the other end a root certification authority that your browser knows about.

So at the end of the day, here’s what happens when you visit a secure website, in somewhat simplified terms:

• The website presents you with its public key as part of the website’s certificate. The certificate has been issued by a certification authority.
• Your browser verifies that this certification authority has been certified, directly or indirectly by a root certification authority it knows about.
• When satisfied that the public key it has received really belongs to the website you are visiting, it then starts transferring data encrypted with this public key
• The receiving website then uses its private key to decrypt the data it receives, and to encrypt its response.