# When is a private and public key given to a user, and why can the private key not get hacked?

Trying to understand assymetric encryption. To my knowledge, it deals with the key management problem by having each user have their own private key and public key. But when is this private and public key pair generated for the user? Does each user have a unique and persistent private and public key?

Also, why are hackers unable to get a private key?

• What you mean by when is priv/public key generated? Whenever you want bro. Jan 14, 2021 at 18:18
• Its not that hackers cannot get the private key, they totally can if you leave your private key lying around unsecured. A private typically cannot be derived from the public key efficiently, and that's what makes it useful in public key crypto systems. Jan 14, 2021 at 18:42
• Normally a user generates his/her own key pair. If someone else generated a private key for you, that would not be secure, because the person that generated it for you knows your private key, so it's not really private. The reason hackers cannot easily get your private key given your public key is that assymetric encryption is based on `trap door` functions - e.g. functions that are easy to compute in one direction, but very hard to reverse. See youtube.com/watch?v=mxLfrZrXC-g for a good, easy to understand video on this subject. Jan 14, 2021 at 18:42

Asymmetric encryption uses a keypair consisting of a public and private key; each pair of keys are generated together at the same time.

Asymmetric means "not the same". In cryptography, we use it to mean "What the public key of a keypair encrypts, only the corresponding private key can decrypt." The pair of keys are mathematically related to each other, but knowing the public key does not enable anyone to figure out the private key. You can think of it this way: the public key lets you create a math equation so hard that only the private key can solve it.

Asymmetric cryptographic algorithms allow me to publish my public key, and then anyone can use it to encrypt data. But only my private key can decrypt the message encrypted with my public key. And when I say publish a public key, I mean just that -- the encryption is so safe I can literally paint my public key on a billboard if I want.

The public key is only half of my keypair. What do I do with my private key? I must keep it secret. Otherwise, anyone with my private key can read those secret messages meant only for me.

When do I create a keypair? Obviously I have to create it and "publish" my public key before you can encrypt any data to send to me.

So if I have a keypair, and I publish my public key; and you have a keypair and you publish your public key, we can then each encrypt messages to send to each other. As long as we keep our private keys safe, nobody knows what we're saying to each other. Although they can still see me sending messages to you, and they can see you sending messages to me, nobody else can read them.

But immediately a problem springs to mind: if someone publishes a public key and says "This key belongs to SuperDuperStore; please encrypt your credit card and send it to them", how do you know if that public key really belongs to SuperDuperStore, and not EvilHackers?

The primary way that's been solved is through the use of "digital certificates", and this is where it gets more complicated. A certificate uses another form of asymmetric cryptography known as a digital signature. The digital signature uses a keypair just like our encryption, but instead the private key is used to create a "signature" of your public key. The signature is a big number that only the signer's private key can create, but anyone with the signer's public key can verify it. The signature and the public key are put together in a specially formatted data structure called a certificate. So if you know you have a copy of the signer's certificate (containing SuperDuperStore's public key), you can use the signer's public key to verify that only the signer could have created the signature.

We call these signers of other people's keys "Trusted Certificate Authorities", or CAs for short. Their job is to prove to everyone that a public key really belongs to SuperDuperStore by signing those certificates. They do this by verifying that each request to sign a public key really came from SuperDuperStore, or Sangstar, or John. Once they verify the request, they digitally sign your certificate request and send you back the signed certificate.

But now it's turned into a chicken-and-egg problem - how do you trust that you have the CA's real public key? First, we have the CA sign their own public key, creating what is called a self-signed certificate. It's a secure document, but how do we know it's not just self-signed by EvilHackers? By only trusting delivery of those self-signed certificates to trustworthy entities. That copy of Windows, or MacOS, or Firefox, or Chrome, or Android, or iOS, or Linux that you're using right now? It was shipped to you with over a hundred trusted self-signed certificates pre-installed. Any self-signed certificate that's not already on the list wasn't signed by a trusted CA, and your browser or computer will reject it, warning you that it is not a legitimate certificate.

Finally, you asked if these keys are persistent, or if they're constantly changed. The answer is on the signed certificates containing the public keys. Each certificate has a "Not After" (expiration date) field, and once a certificate is too old, it is no longer trusted by anyone else. Before that happens you'll want to get a new certificate and publish it; it turns out this is usually a good time to generate a new keypair, too.

• Who does the signing? SuperDuperStore or a trusted third party? Jan 15, 2021 at 14:26
• The trusted third party (the CA) does the signing. We all agree in advance that the CA is someone we'll all trust to properly sign certificates. Jan 15, 2021 at 14:27