I offer a different view that helped me to understand things back in the day.
Asymmetric cryptography works using as base a couple of two big numbers that are computed in some way, so they are related. We call them keys or
2 parts of one key.
However the following property holds:
- if you have only them, you can not compute one just from the other
- the algorithms in place give you the fact that anything encrypted by one of this number can only be decrypted by the other number (and not even by using the first number, this is a key property).
Now, on top of that we decide that one of the two is public and we will distribute it globally (in X.509 certificates, on public OpenPGP keyservers, etc.) while the other is private and everything should be made secure so that only the entity (it can be an individual, an organization, an host, an email address, etc.) covered by it is the only one knowing this "private" part.
So if you imagine everyone has these 2 parts and all public parts are known, trusted and secure (we will see there are problems here) you can have the following things, if we take Alice and Bob:
- everything Alice encrypts with Bob public key can only be decrypted by Bob (because he should be the only one having the corresponding private key)
- everything Alice encrypts with her private key can be decrypted by anyone using her public key (which is by definition public and available to everyone).
You may find the second point useless. It is not, it is the basis of authentication in fact. Because normally only Alice has her private key so if you are able to decrypt something with her public key then you know that it was encrypted with Alice private key so it means it was done by Alice, you have proved authentication.
Now of course the problem is how you publish all public keys, because anyone could publish a key saying it is for "email@example.com".
How is this solved?
- in the X.509 PKI world, public keys are not managed like that but through a X.509 certificate (often called "SSL certificate" which is doubly wrong because TLS superseded SSL 20 years ago and because you can do TLS without certificates at all), which is basically a public key plus a begin and an end date and a signature. What is the signature? It is a computation carried over all the content of the certificate (hence the public key) done by the private key tied to another certificate, typically a "certificate authority" (normally there is a chain of them but that does not change the generic idea). And you ultimately trust some CAs, so that you have their public key and you validate any certificate that is validly signed by private keys of these CAs.
- in the OpenPGP web of trust, in fact anyone as a local/individual decision can say how much he trusts a given key; the idea is that normally the two individuals meet in real life, even show official ID documents, and only after that can say "yes key X is really belonging to such individual".
So my question is, what stops an attacker listening in from just grabbing the key which you send alongside the data? If it's not actually being sent alongside the encrypted data, then at what point does the server receive the key that it needs to decrypt?
Let us take a typical HTTPS handshake that uses HTTP over TLS
(see https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake for a complete explanation)
You can look at this diagram for TLS 1.3: https://tools.ietf.org/html/rfc8446#section-2 ; you will see there that each
Certificate message is in fact itself encrypted with keys derived from previous exchanges (the
ServerHello messages that each include a random secret).
Remember also that if you trust a given CA (that it its private key) you trust anything signed by it, that is any end client certificate having a signature made by its private key (that hence everyone could verify using its public key).
Anyone intercepting the
ServerHello and replying it will not be able later to prove it has the corresponding key associated to the certificate sent with the
Certificate message. This is also why authentication is so important: without it you can have a secure as in encrypted stream but without any idea on who you are talking to, which could be a man in the middle relaying the traffic.
ClientKeyExchange message: "which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate." and hence only the server (having the corresponding private key) will be able to decrypt it and go forward. Same for the other direction.