How public-key cryptography works

For most of the digital age, it’s been easy to take for granted that we can send a private message to someone across the globe with a reasonable expectation of privacy. We also trust that the message will arrive in its original form. But in a world where anyone can publish anything or claim to be anyone, can we trust that our communication online is authentic and secure?

One of the most critical techniques for enabling online security is public-key encryption, also known as asymmetric encryption. The basic idea is that the sender encrypts information using a public encryption key provided by the recipient. The recipient uses their distinct (and secret) corresponding private key to decrypt this information.

But how does this work, conceptually? If a public key is used to encrypt information, why can’t this same public key be used to decrypt the information? We’ll get into that, but first, an analogy:

Public-private key pairs and one-way functions

Think of public-key encryption as a locked mailbox with a known location. The address is the public “key.” The mailbox’s owner never shares their private (literal) key to unlock it. Anyone can send a message to the box, but only the owner can read those messages.

Online, locking is accomplished via a one-way mathematical function. This function allows data to be encrypted by a public key, but the same public key cannot be used to decrypt the newly encoded data.

The public key can’t be used to fish the letter out of the locked mailbox. Only the corresponding private key can obtain the letters inside.

How does public-key encryption work for two-way communication?

Taking this a step further, consider the problem of person A wanting to communicate securely with person B. This can be accomplished via the following methodology:

• Person A generates and shares public key Ax; generates and keeps private key Ay
• Person B generates and shares public key Bx; generates and keeps private key By
• Person A encrypts to-be-sent message A1 with public key Bx as A1e, and sends this encrypted message to person B. Person B then decrypts message A1e back into A1 with private key By
• Person B encrypts to-be-sent reply B1 with public key Ax as B1e and sends this encrypted message to person A. Person A then decrypts message B1e into B1 with private key Ay.

The important thing here is that private keys are never shared, and public keys can be shared in the open since they cannot encrypt and decrypt the same message. Once a message is encrypted for transmission, even the encrypting entity can’t view what’s in the message because it doesn’t have the private key.

Sender verification

While you cannot read an encrypted message without the private key, anyone can encrypt a message with your public key for your private key. Jumping back to the mailbox analogy, while a trusted friend can drop a note in your locked mailbox, so can junk mail purveyors, scammers, and other uninvited entities. One might even put a trusted associate’s name on the envelope—perhaps claiming that he’s in a precarious situation and needs a large sum of cash, Apple gift cards, Krugerrands, or other assets.

Here the mailbox analogy starts to break down; however, public-key cryptography does allow for sender verification. For this process to work, A and B generate a public and private key pair for two-way verified communication. Then, each message is encrypted twice: once with the sender's private key and again by the recipient's public key. To both secure and verify communications:

• A encrypts to-be-sent message A2 using private key Ay, plus public key Bx as A2e.
• B decrypts message A2e using public key Ax, which verifies that A2e was generated with private key Ay, thus verifying the identity of the sender. Person B then further decrypts this message using private key By into usable data.

Thus, the same key pairs initially generated can be used for both basic asymmetric communication as well as verified asymmetric communication. The fundamental difference being that only two keys total need to be used in basic asymmetric exchanged per message; for verification three total keys are used per message.

Note that public keys are not one-way functions in and of themselves but are used as inputs to one-way functions to properly encrypt data.

While humans are broadly discussed here as encrypting/decrypting data, such operations don’t have to be directly initiated by humans. Protocols like TLS/SSL that enable secure website browsing use asymmetric encryption. This type of encryption is essential to blockchain operations.

Asymmetry Enables Symmetry

Before the advent of asymmetric encryption in the 1970s, symmetric key encryption—where each side of a transmission needed the same sort of rules to exchange messages—was how communications could be shielded from interception. In the age of the Internet, where you may never come into physical contact with the person or non-human entity with whom you’re exchanging messages (and passing a key in the open poses security risks), symmetric encryption is fraught with difficulties.

At the same time, symmetric encryption is still desirable in many cases. The TLS/SSL protocol, which makes HTTPS possible on the Web, uses asymmetric encryption to pass along symmetric encryption “session” keys. Session keys are then used to facilitate private communication between the two entities via symmetric encryption.

From a practical standpoint, strong security using techniques like public-key encryption allows us to communicate online with a reasonable expectation of privacy. This also enables smart devices like Alexa and Google Home to stay secure, establishing trust that one’s activities aren’t being shared in nefarious or simply unwanted ways.

Find security solution products such as authenticators at Arrow.com, including some of our popular products below.