-2

If I am not wrong, both private key and public key are the same since communication is possible only if both keys are matching. So, why we should only keep the private key secret, why not public key? When I generate a key by ssh-keygen command, and save it on a directory, is it a public key or private key?

Glorfindel
  • 2,235
  • 6
  • 18
  • 30
Sann
  • 33
  • 3

2 Answers2

3

If I am not wrong, both private key and public key are the same

Unfortunately, you are wrong. The private key and the public key are not the same.

The entire idea of public key cryptography depends on this difference. The public key is public, it can be published, it can be widely disseminated. The private key is private, it must be kept secret.

In practice, the form of the public key data may be similar to the form of the private key data, but the data is different and their function is very different. For example, the public key might be a large integer N and a small "encryption exponent" e whereas the private key might be that same large integer N and a "decryption exponent" d. Nevertheless, d and e are different (e is often well known whereas d is not).

since communication is possible only if both keys are matching. So, why we should only kept the private key secret, why not public key? When I generate a key by ssh-keygen command, and save it on a directory, is it a public key or private key?

In SSH, you use the private key to log into an ssh server. This server keeps your public key in the "authorized keys" directory. This DIRECTORY must also be protected--not necessarily the public keys in the directory. If anyone is allowed to put their public key in this directory then anyone will be able to login. So the authorized keys directory must be protected.

In this SSH use case, you probably just so happen to keep the public key secret too, but it doesn't necessarily have to be kept secret.

If you use the "ssh-keygen" command, it generates both the public and private key. The private key will probably be called something like "id_rsa" and the public key will probably be called something like "id_rsa.pub".

hft
  • 4,910
  • 17
  • 32
  • 1
    @MartinPrikryl I don't think that's true. I just created one to test, and the private key file contains a single base64-encoded block, delimited by "BEGIN RSA PRIVATE KEY" and "END RSA PRIVATE KEY"; if the public key is in there explicitly, it's not in a format that's trivial to extract. It is however true that you can _derive_ the public key from the private key, which may be what you're thinking of? – IMSoP Mar 25 '21 at 13:06
  • can I use `chmod 400 authorized keys` command to protect the authorized keys directory. – Sann Mar 25 '21 at 14:31
  • Many tutorials that I've seen on setting up an ssh server suggest `chmod 600 authorized_keys` rather than `chmod 400` – hft Mar 25 '21 at 18:22
  • I've never tried `chmod 400` on that directory, but `chmod 600` should be fine. – hft Mar 25 '21 at 18:24
  • @MartinPrikryl You *can* derive the public key from the private key in many cases. You can *not* derive the private key from the public key. For example, In RSA the public key is (N,e) where e is usually a well-known small prime (e.g., 0x10001). OTOH, in RSA the *private* key is (N,d) where d is *not* well-known. Therefore you can derive public from private in this case, but not private from public. – hft Mar 25 '21 at 18:29
  • Not that this matters much, since the private key data structure usually already also contains the public exponent (since it is public). But clearly the public key data structure must not contain the private exponent. – hft Mar 25 '21 at 18:32
1

A common analogy for asymmetric cryptography is a padlock and key. Like most analogies, it will fall down if taken too far, but I think it serves as a good top level explanation for questions like this.

The analogy goes something like this:

  • Alice wants to put something in a locked box, and let Bob open it, but she's worried someone will make a copy of the key if she sends it to Bob in the post.
  • Bob has a padlock which can be closed without the key, but only he has the key to open it. He doesn't mind if anyone makes identical padlocks, because that won't help them open anything, so he makes it available to anyone who wants it.
  • Alice takes Bob's padlock, and uses it to lock her box. Bob is now the only person who can unlock the box - not even Alice herself can do that.

For an SSH login, this corresponds to this:

  • Alice want to make a server secure, and let Bob log into it, but she's worried someone will make a copy of the password if she send it to Bob over the internet.
  • Bob has a public key which can be used to encrypt things, and only he has the private key to decrypt them. He doesn't mind if anyone copies the public key, because that won't help them decrypt anything, so he makes it available to anyone who wants it.
  • Alice takes Bob's public key, and marks it as the trusted key for an SSH user. Bob is now the only person who can log in as that user.

(As I said, the analogy soon falls down - in this case, you can authorise multiple public keys for the same SSH user. I guess you could say that there's a row of boxes locked with different people's padlocks, or something.)

Asymmetric keys always come in pairs, by definition. The ssh-keygen command will generate two files: one is the public key (the "padlock") which you can share however you like; the other is the private key (the "key") which you must keep secret.

IMSoP
  • 3,780
  • 1
  • 15
  • 19