*This is part of a weekly series on the Clef blog: What is That: 5-Minute Blogs on Understanding and Using Security Concepts. For more posts, go here.*

One of the security terms we commonly use when talking about Clef is *asymmetric cryptography*. For users well versed in technology and security, the term often leads to an instant understanding of how Clef works. Most of time, however, we’re met with blank stares and confusion.

Today, we’ll take a quick dive into what asymmetric cryptography is and how you can use it every day.

#### Sending secret messages

Imagine you have a secret message that you want to tell a friend on the other side of the country. How would you get the message to them securely?

Here is one possible solution.

First, mail your friend an *encryption key*. Consider this *encryption key* as a way that you will make the message you send unreadable to anyone who doesn’t have the *encryption key*. Next, in another letter, encrypt your message with that *encryption key* and mail it to your friend.* *When your friend gets the encrypted message, they will already have the *encryption key, *so they will be able to decrypt read it.

This method is problematic because if an attacker intercepts the *encryption key* they’ll be able to read your message as well! If you were to send a lot of messages with the same *encryption key*, this could be a very dangerous proposition.

Now, consider a second possible solution.

Imagine that your friend has two encryption keys: a *private key* and a *public key*. The *public key* can encrypt messages that only the *private key* can decrypt. First, your friend mails you their *public key*. Second, you use your friend’s *public key* to encrypt a message and you send the encrypted message back to them. Finally, your friend uses their *private key* to decrypt and read the secret message.

With this new method, even if an attacker intercepts the *public key ***and** the message, they won’t be able to decrypt it because only the *private key* can decrypt. Since the *private key* never leaves the hands of your friend, it has no chance of being intercepted during transmission and you can continue communicating securely without worry of eavesdropping!

The first solution we outlined is **symmetric cryptography**. It’s *symmetric* because the same piece of information (the *encryption key*) is required on both sides — adding the possibility of interception when it’s passed from one side to the other.

The second solution is **asymmetric cryptography **(also known as public-key cryptography). It’s *asymmetric* because we use a **different** **key** on each side to decrypt and encrypt — we never have to transmit the key used for decryption, so there’s no risk of interception.

#### What are passwords?

One good example of **symmetric cryptography** is passwords. For you to use a password, you have to pass it from your brain to the website you’re logging into. On their end, they have to store it so they can verify it in the future. If your password gets intercepted while it’s passing from your brain to the website (if someone is watching you type or sniffing your internet connection), the attacker could use it to impersonate you. Similarly, if an attacker got a hold of unencrypted passwords from a website’s database, they could use them to log in as the users they belong to. These flaws exist because in **symmetric cryptography** the same information is needed on both sides to decrypt messages or verify identity.

#### What is Clef?

Clef is an example of **asymmetric cryptography**.

When you sign up for Clef on your phone, we generate a *private key* and *public key* and send the public key to our server. Whenever you log in, we send a message with the *private key* to our servers. This message, since it is sent by the *private key,* can be verified by the *public key* as uniquely belonging to you; however, only the *private key* (and not the *public key*) can generate these messages. Therefore, even if an attacker had the *public key, *they would not be able to log in as you. To do that, they would need your *private key*, which is generated on the phone, stored encrypted on the phone, and never transmitted anywhere.

#### Learning more

If you’re looking for an approachable, but more in depth, look into asymmetric cryptography, I highly recommend reading Ars Technica’s piece on the subject.

If you want to know how awesome **asymmetric cryptography** can be, give Clef a try.

*Jesse is one of the co-founders of Clef. Follow him on Twitter here.*

Joseph Wegner

As I was reading this article, I was reminded of the insane tongue twister I always fight with when explaining asymmetric cryptography. “Public key” and “Private key” are pretty easy to get mixed up, especially if you’re new to crypto.

I was trying to think of a good analogy, and I thought of wax seals ( http://en.m.wikipedia.org/wiki/Seal_(emblem) ). A long time ago – long before proper crypto practices – people used to send sensitive information in envelopes sealed with wax stamps. These stamps had intricate emblems in them – presumably too intricate to copy.

This is cool because it allowed the receiver to definitively verify the sender of the message, as well as the fact that the contents of the envelope haven’t been tampered with. these are the same benefits we get from asymetric crypto.