Privacy stalwart Nicholas Merrill spent a decade fighting an FBI surveillance order. Now he wants to sell you phone service—without knowing almost anything about you.
don’t they also receive the public keys and can then also decrypt the messages??
A public key is used to encrypt a message, you need the private key to decrypt.
That’s why you have public key servers. it doesn’t matter who has the public key, all they can do with it is encrypt information that only the private key holder can decrypt.
The more I think about it, the more I am convinced I don’t understand how any encryption works because the intended recipient needs the key to decrypt it
The way it was explained to me that finally made it click was so:
Imagine you have a lockable box (public key) and a key (private key), the box is empty so you give it to your friend. it doesn’t matter if anyone sees the open box because there’s nothing in it. your friend puts something private for you in the box and locks it. People see the box as he’s bringing it to you but they can’t see what’s in the box because neither him nor the people watching have the key to the box; only you do. once it gets to you you can open the box with your key
OH. So like, it’s a situation where the “lock” has 2 keys, one that locks it and one that unlocks it. You keep the “unlock” key on your person and never let it out of your sight, but let the “lock” key just gets distributed and copied anywhere because all it can do is LOCK the door, and it really doesn’t matter who locks the door so long as only you can unlock it.
That is very interesting. I still don’t quite understand how it technically works, because I thought if you encrypt something with a key, you could basically “do it backwards” to get the original information… This is probably due to getting simplified explanations of encryption though that makes them analogous to a basic cipher (take every letter, assign it to a number, add 10, convert back to new letter - can’t be read unless someone knows or figures out the “key” is 10) and now it is obvious that it is significantly more complex than that…
But I am much more confident that I understand the ‘mechanics’ of it, so thank you for the explanation!
I thought if you encrypt something with a key, you could basically “do it backwards” to get the original information
That is how it works in symmetric encryption.
In many real-world applications, a combination of the two is used: asymmetric encryption is used to encrypt - or to agree upon - a symmetric key which is used for encrypting the actual data.
Here is a simplified version of the Diffie–Hellman key exchange (which is an asymmetric encryption system which can be used to agree on a symmetric key while communicating over a non-confidential communication medium) using small numbers to help you wrap your head around the relationship between public and private keys. The only math you need to do to be able to reproduce this example on paper is exponentiation (which is just repeated multiplication).
Here is the setup:
There is a base number which everyone uses (its part of the protocol), we’ll call it g and say it’s 2
Alice picks a secret key a which we’ll say is 3. Alice’s public key A is ga (23, or 2*2*2) which is 8
Bob picks a secret key b which we’ll say is 4. Bob’s public key B is gb (24, or 2*2*2*2) which is 16
Alice and Bob publish their public keys.
Now, using the other’s public key and their own private key, both Alice and Bob can arrive at a shared secret by using the fact that Ba is equal to Ab (because (ga)b is equal to g(ab), which due to multiplication being commutative is also equal to g(ba)).
So:
Alice raises Bob’s public key to the power of her private key (163, or 16*16*16) and gets 4096
Bob raises Alices’s public key to the power of his private key (84, or 8*8*8*8) and gets 4096
The result, which the two parties arrived at via different calculations, is the “shared secret” which can be used as a symmetric key to encrypt messages using some symmetric encryption system.
You can try this with other values for g, a, and b and confirm that Alice and Bob will always arrive at the same shared secret result.
Going from the above example to actually-useful cryptography requires a bit of less-simple math, but in summary:
To break this system and learn the shared secret, an adversary would want to learn the private key for one of the parties. To do this, they can simply undo the exponentiation: find the logarithm. With these small numbers, this is not difficult at all: knowing the base (2) and Alice’s public key (8) it is easy to compute the base-2 log of 8 and learn that a is 3.
The difficulty of computing the logarithm is the difficulty of breaking this system.
It turns out you can do arithmetic in a cyclic group (a concept which actually everyone has encountered from the way that we keep time - you’re performing mod12 when you add 2 hours to 11pm and get 1am). A logarithm in a cyclic group is called a discrete logarithm, and finding it is a computationally hard problem. This means that (when using sufficiently large numbers for the keys and size of the cyclic group) this system can actually be secure. (However, it will break if/when someone builds a big enough quantum computer to run this algorithm…)
A public key is used to encrypt a message, you need the private key to decrypt.
That’s why you have public key servers. it doesn’t matter who has the public key, all they can do with it is encrypt information that only the private key holder can decrypt.
The way it was explained to me that finally made it click was so:
Imagine you have a lockable box (public key) and a key (private key), the box is empty so you give it to your friend. it doesn’t matter if anyone sees the open box because there’s nothing in it. your friend puts something private for you in the box and locks it. People see the box as he’s bringing it to you but they can’t see what’s in the box because neither him nor the people watching have the key to the box; only you do. once it gets to you you can open the box with your key
OH. So like, it’s a situation where the “lock” has 2 keys, one that locks it and one that unlocks it. You keep the “unlock” key on your person and never let it out of your sight, but let the “lock” key just gets distributed and copied anywhere because all it can do is LOCK the door, and it really doesn’t matter who locks the door so long as only you can unlock it.
That is very interesting. I still don’t quite understand how it technically works, because I thought if you encrypt something with a key, you could basically “do it backwards” to get the original information… This is probably due to getting simplified explanations of encryption though that makes them analogous to a basic cipher (take every letter, assign it to a number, add 10, convert back to new letter - can’t be read unless someone knows or figures out the “key” is 10) and now it is obvious that it is significantly more complex than that…
But I am much more confident that I understand the ‘mechanics’ of it, so thank you for the explanation!
Precisely :) This is called asymmetric encryption, see https://en.wikipedia.org/wiki/Public-key_cryptography to learn more, or read on for a simple example.
That is how it works in symmetric encryption.
In many real-world applications, a combination of the two is used: asymmetric encryption is used to encrypt - or to agree upon - a symmetric key which is used for encrypting the actual data.
Here is a simplified version of the Diffie–Hellman key exchange (which is an asymmetric encryption system which can be used to agree on a symmetric key while communicating over a non-confidential communication medium) using small numbers to help you wrap your head around the relationship between public and private keys. The only math you need to do to be able to reproduce this example on paper is exponentiation (which is just repeated multiplication).
Here is the setup:
gand say it’s 2awhich we’ll say is 3. Alice’s public keyAis ga (23, or2*2*2) which is 8bwhich we’ll say is 4. Bob’s public keyBis gb (24, or2*2*2*2) which is 16Now, using the other’s public key and their own private key, both Alice and Bob can arrive at a shared secret by using the fact that Ba is equal to Ab (because (ga)b is equal to g(ab), which due to multiplication being commutative is also equal to g(ba)).
So:
16*16*16) and gets 40968*8*8*8) and gets 4096The result, which the two parties arrived at via different calculations, is the “shared secret” which can be used as a symmetric key to encrypt messages using some symmetric encryption system.
You can try this with other values for
g,a, andband confirm that Alice and Bob will always arrive at the same shared secret result.Going from the above example to actually-useful cryptography requires a bit of less-simple math, but in summary:
To break this system and learn the shared secret, an adversary would want to learn the private key for one of the parties. To do this, they can simply undo the exponentiation: find the logarithm. With these small numbers, this is not difficult at all: knowing the base (2) and Alice’s public key (8) it is easy to compute the base-2 log of 8 and learn that
ais 3.The difficulty of computing the logarithm is the difficulty of breaking this system.
It turns out you can do arithmetic in a cyclic group (a concept which actually everyone has encountered from the way that we keep time - you’re performing
mod 12when you add 2 hours to 11pm and get 1am). A logarithm in a cyclic group is called a discrete logarithm, and finding it is a computationally hard problem. This means that (when using sufficiently large numbers for the keys and size of the cyclic group) this system can actually be secure. (However, it will break if/when someone builds a big enough quantum computer to run this algorithm…)Amazing, thank you for the in-depth (but simple enough) explanation!
Yep, you lock with the public key and unlock with the private.
You can’t unlock with the public, it’s one way only