This is in fact one of the great challenges in encryption – [key exchange](https://en.wikipedia.org/wiki/Key_exchange).

Historically this was done by using a pre-shared key – physically meeting and exchanging the keys.

However there are better ways to exchange keys. One way is the [Diffie Hellman key exchange](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange). The idea is that each party generates some secret number x, uses it to calculate another number y, and shares it with the other party. Then both parties use those numbers to calculate some shared number z, which serves as their encryption key.

Another way is public key encryption. Standard (symmetric) encryption uses the same key to encrypt and decrypt. Public key, or asymmetric encryption, such as [RSA](https://en.wikipedia.org/wiki/RSA_(cryptosystem)), has different keys. Every person has a set of public and private keys. When something is encrypted with the public key, it can then be decrypted with the private key. Usually you don’t encrypt the entire data with this mechanism – instead, you randomly generate a key to be used in symmetric encryption, then you can encrypt that key using the recipient’s public key.

There really isn’t a “ELI5” answer to modern cryptography. It is very complex.

The high-level answer is that there is a type of cryptography that uses two keys – one to encrypt and one to decrypt. Having one key doesn’t help you – you can have encrypted data _and_ the encryption key and you _still_ can’t decode the data; you have to have the decryption key to decrypt.

This means that you can make the encryption key public – tell anyone who wants to send you encrypted data to use that encryption key. You then keep the decryption key a secret – only you know it. The result is anyone can send you encrypted data – even folks you don’t have prior contact with – and you can be confident the data is secure. This is the basis for almost all modern web traffic security.

You tell me your **lock** code, but you keep your **unlock** code secret.

Anyone, anywhere, can lock anything using your **lock** code. It is then encrypted and secure. But *only you* can then **unlock** it, because only your **unlock** code will work.

So the **lock** codes can be freely given out and it doesn’t matter, because even with the **lock** code, no one else can **unlock** it.

Imagine you take a bunch of cocoa and a bunch of flour and mix them together in a bowl, and then give the bowl to someone else and ask them to separate the cocoa and flour. Could they do it? In principle, sure. They could get out a magnifying glass and some fine tools, and then go through and separate the mixture little by little. But it would take a *very* long time to do this.

Suppose however that you–and only you–have a special machine that can separate cocoa and flour really quickly. What you now have are the tools for something that’s basically how the most widely used public-key encryption protocol, RSA, works. You can ask someone else to take a bunch of cocoa and flour (the “message”), mix it together (“encrypt” it) and then send it to you. If anyone else intercepted the mixture, yes, they could in principle separate (“decrypt”) the mixture, but the amount of time it would take to do so would likely be prohibitive. Thus, only you, who has the special separation machine, can actually decrypt the message in practice.

RSA public-key encryption works very similarly. I first create a decryption function. I then reverse (or “invert”) that decryption function to get an encryption function, so that if a message is first passed through the encryption function, and then the result is passed through the decryption function, you get the original message back.

In principle, the encryption function could itself be inverted to get the original decryption function, in which case if you know the encryption function then you can also figure out the decryption function. But it turns out (and this is the real genius of this system) that there are ways to do this where the initial inversion (decryption function -> encryption function) is way, *way* easier than going in the opposite direction (encryption function -> decryption function). As a result, if I gave you the encryption function only, then given an infinite amount of time you could definitely recover the decryption function, but you simply won’t be able to do it within a time frame that’s practically useful (e.g., it might take 5000 years).

So what I can do is create a decryption function, invert it to get the associated encryption function, and then send the *encryption function only* to the partner I want to receive a secret message from. My partner can then encrypt their message using that function and send it to me. If that encrypted message gets intercepted by someone, then even though they may have also intercepted the encryption function, since they can’t in practice invert it to get the decryption function, they won’t be able to decrypt the secret message.

there are two types of crypto:

-symmetric where the same key encrypt and decrypt stuff, so for those you need to pre-share the key over a secure channel, for example you meet in person and exchange the key just once and then you exchange message remotely forever.

-asymmetric: one key encrypt, another different one decrypt (think about sending to a friend an opened safe, he can insert stuff, close it and send back it to you but he or anyone can’t open it because he doesn’t know the code) so you can publish over the internet the one that encrypt stuff (public key) so that everyone can encrypt messages but only you have the other key that decrypt (private key).

a eli5 description of asymmetric encryption is this one: [https://en.wikipedia.org/wiki/Merkle%27s_Puzzles](https://en.wikipedia.org/wiki/Merkle%27s_Puzzles) basically you make many simple puzzles that when solved show a something, you send all of them to another person, they get intercepted and duplicated, the person solve 1 random puzzle and send you the secret message on the puzzle, now you both know a secret number: which puzzle was solved

for example:

puzzle number 1: when solved display “hello”

puzzle number 2: when solved display “asdfg”

puzzle number 3: when solved display “abcd”

the other side solve one random and send you “asdfg” (which gets intercepted too but it doesn’t matter) so now you both have shared a secret: “2” because even if someone intercepted the whole thing he needs to solve all puzzles to find out that “asdfg” was puzzle 2 while the guy that solved just 1 random puzzle he already knows that he picked the second one and you that are the author created all those puzzles so you know which is the second, this is an eli5 and it’s unsafe but it’s possible with math to create problems simple to create but hard to solve.

there are more problems:

-for exmaple what if in the asymmetric example one attacker instead of intercepting everything also replace your public key with his one?

the way this is solved in real world is PKI: public key infrastructure, to keep it simple when you buy a pc it already have some keys inside that are trusted and those keys are used to generate more keys by trusted people.

You don’t encrypt with the same key used to decrypt. Every person has their own private decrypt key, and their public encrypt key that anyone can get. If I want to send a message to Obama, his encrypt key is public so I get that and use it to encrypt the message which then only he can decrypt using his private key.

This is made possible because of math, your public key is a very large number that people use to encrypt messages sent to you, now it’s impossible to decrypt that message without knowing the two prime factors making up that large number.

Public key cryptography is basically built around key pairs. You generate a pair of keys and you share one (the public key) and you keep one secret (private key).

Anything encrypted with one key can only be decrypted by the other. So anyone can encrypt data (using public key) and only you can decrypt it (using private key). The public key is not and does not need to be secret.

The opposite can be done too (although you should use a different key pair). You could encrypt something with your private key, and then ANYONE could decrypt it with the public key. The information isn’t secret, but a recipient will know it came from you (anyone else would not have been able to encrypt it – if it was encrypted with a different private key, then using my public key to decrypt would just yield gibberish)

The reason that the key pairs work and that you can’t use the same key both encrypt and decrypt is really mathy, but you don’t really need understand that if you just remember that one key reverses what the other key does. One key alone does not allow you to reverse.

## Latest Answers