1

As far as I've learned, I have to keep the private key secure and publish the public key, so that anyone can encrypt any data using public key and I can decrypt it using my own private key (which nobody has).

The question is, what if I publish the private key and keep the public key? Again the algorithm seems to work: anybody locks the data with the private key (which is published), but no one has the public key (which is kept secure by me).

What makes a public key, a public key? What secure and important data is stored on private key which I should show no one?

Mohammad Kholghi
  • 533
  • 2
  • 7
  • 21
  • 1
    I’m voting to close this question because it belongs at [crypto.se]. – n. m. could be an AI Sep 04 '21 at 06:33
  • @n.1.8e9-where's-my-sharem. I've seen a lot of questions about SSL and key-pairs on SO. I don't get why mine is different. Would you please explain more? – Mohammad Kholghi Sep 04 '21 at 06:36
  • A private key works like a public key but can also decrypt the encrypted text. So publishing the private key is not a good idea. Only the public key should be known by others. If this is not the case you have to revoke the key and create a new keypair and only publish the public one. –  Sep 04 '21 at 06:52
  • Also with the private key anyone can pose as you. –  Sep 04 '21 at 06:52
  • @DanielRuf Thanks. For the first comment, AFAIK, the private key can be used to encrypt the data (signing it, to be more specific), so anyone with a public key can make sure that I have the private key, and I am ME (Authorization purpose). You said: `A private key works like a public key but can also decrypt the encrypted text.` A public key can decrypt the encrypted data too. For the 2nd comment, both keys have the same fingerprint, so why with a public key no one can pose as me? – Mohammad Kholghi Sep 04 '21 at 07:03
  • @DanielRuf While all of that is true, I think the question is about something else. technically, it works both ways: If you have a block of data, you can encrypt/sign it with either the public or the private key. And you can decrypt/verify it with the respective other. So in theory it would also be possible to give out the private key and keep the public key secret. But the practial problem is, that in many cryptosystems, the public key can be derived from the private key, but not vice versa. – derpirscher Sep 04 '21 at 07:05
  • @DanielRuf So if you want make the private key (A) public and keep the public key (B) secret, your system will be compromised, because anybody can easily derive (B) from the known (A). But cryptosystems like RSA work, because it's generally not possible to deriave (A) from a known (B). Thus, while it's mathematically possible to switch the roles of private and public key, it won't be secure at all ... – derpirscher Sep 04 '21 at 07:08
  • No, the private key can do encrypt + sign + decrypt. The last part should be only possible for you, not others. Please never publish the private key. Public key is used for encryption but not more. –  Sep 04 '21 at 07:49
  • Exactly, anyone can derive the public key from the private one. Hence the name, private = yours (should be kept private / secure normally). –  Sep 04 '21 at 07:52
  • @DanielRuf @DanielRuf One reason to hold the private key is that someone else can generate public keys, related to my private key. OK, it's fine, I understand. Another reason you talked about is: `private key can do encrypt + sign + decrypt. The last part should be only possible for you, not others.` The Public key can decrypt the data encrypted with private key, respectively. I don't get why you say it's just possible with private key. – Mohammad Kholghi Sep 04 '21 at 09:20

2 Answers2

3

For a complete encrypt + decrypt (or sign + verify) process you always need BOTH keys. One for encryption/signing and the other one for decryption/verifying. Which of the keys you use for which operation is (in principle) irrelevant, as long as you use the respective other one for the inverse operation.

So let's assume you used a tool like openssl to generate a key-pair A and B.

When it comes to publishing one of those keys, we have to take into account two aspects

  • Math: From a pure mathematics point of view (and leaving out the security for a moment), it's irrelevant which of the keys you make public and which you keep private. All processes will work either way.

    decrypt(encrypt(data, A), B) == data == decrypt(encrypt(data, B), A) verify(sign(data, A), B) == OK == verify(sign(data, B), A)

  • Security: When we take security into account, proving your identity via digital signature is only possible, if you use a key, nobody else can possibly know. For certain crypto systems, it's possible to derive key A from key B, ie there exists a function such that

    A = f(B)

    but not vice versa, ie there is no function such that

    B = f(A)

    Thus, the moment you know B, you also know A, but if you only know A, there is no possibility you can derive B.

Thus B is called the private key and must kept private, A is the public key, which can be published. If you do it the other way around, the processes will still work from a mathematical point of view (although most systems will reject your keys), but they are not secure anymore ...

derpirscher
  • 14,418
  • 3
  • 18
  • 35
  • Thanks a lot, I understood everything very well by your explanation. I still have 2 questions: 1. Is there a private key `C`, which if `A = f(B)`, `A = f(C)`? I mean if any available (I don't care if we can find it, I want to know the mathematical logic behind it) that creates the same public key? 2. Does private key `B` always gives me the `A` public key? Or with different algorithms (RSA, DSA, ...) I can generate DIFFERENT public keys for ONE private key? – Mohammad Kholghi Sep 05 '21 at 10:51
  • 1
    see for instance https://stackoverflow.com/questions/23930430/can-we-have-multple-private-keys-with-single-public-key or https://stackoverflow.com/questions/9375044/can-we-have-multiple-public-keys-with-a-single-private-key-for-rsa Short answer: Mathematically, there are multiple private keys for a public key, and vice versa. Practical usage: No, this is a 1:1 relation (because of feasability and common standards) – derpirscher Sep 05 '21 at 12:49
1

Depending on the system use, the public key may be 'well known'. For example, with RSA, the public key is just your modulus plus the public exponent 65537, while the private key is the modulus plus the private exponent (which is the real secret). So someone who knows the private key also knows the public key pretty much by default. The same is true of most elliptic curve based systems.

In theory one could make an RSA-style system where the public exponent is also hard to determine (say a randomly generated value of enough bits to be non-guessable), in which case it would be more symmetric, but that is not the way the system is usually set up. In any case someone who knows the secret parameters underlying the keys (the factors of the modulus in RSA) can easily determine the public key from the private key or the private key from the public key.

In systems like Diffie-Hellman, the public key is actually derived from the private key by a well-known algorithm (there are no secret paramters other than the private key itself), so in such cases the keys are not symmetrical at all, and anyone who knows the private key can trivially determine the public key.

Chris Dodd
  • 119,907
  • 13
  • 134
  • 226