4
$\begingroup$

I try to understand the private and the public key concept, and need some validation about my statements:

  1. If I encrypt a message with public key, I can only decrypt with private key.
  2. If I encrypt a message with private key, I can only decrypt with public key.
  3. I can generate public key (derived key) from private key(base key).
  4. I can not generate private key from public key.
  5. Private key name comes how I handle the key: I keep it in secret, so I call it private key.
  6. Public key name comes how handle the key: I publish it, anybody can use it, so this is the public key.
  7. If I publish the base key, I can call it public key
  8. If I keep in secret the derived key, I can call it private key.
Improve this question
$\endgroup$
7
  • 4
    $\begingroup$ "If I encrypt a message with private key, I can only decrypt with public key." You do not encrypt using a private key, ever. $\endgroup$
    – Maeher
    Jan 25, 2019 at 14:32
  • $\begingroup$ May the example is not the best, but based on this article, highlighted the Digital signature part, I do encrypt a message with private key: ogcio.gov.hk/en/our_work/regulation/eto/digital_cert/… $\endgroup$
    – HowToTellAChild
    Jan 25, 2019 at 14:43
  • $\begingroup$ Ad "publish key": In which context have you seen this? Is it in any way related to this? $\endgroup$
    – dkaeae
    Jan 25, 2019 at 14:44
  • 1
    $\begingroup$ @HowToTellForAChild That is sadly a relatively common misconception. It's still completely and utterly wrong. A signature scheme that would work in that way would be absolutely insecure and/or non-functional. $\endgroup$
    – Maeher
    Jan 25, 2019 at 14:47
  • $\begingroup$ @dkaeae not, I was think only to public key, if I mentioned publish key. It was just a mistyping. $\endgroup$
    – HowToTellAChild
    Jan 25, 2019 at 14:52

2 Answers 2

Reset to default
7
$\begingroup$
  1. If I encrypt a message with public key, I can only decrypt with private key.

True, except that public/private keys must match, and there might be several equivalent private keys (as in many definitions of RSA). We should thus say:

In a secure asymmetric encryption system, a message encrypted with a public key can only be decrypted with a matching private key.

  1. If I encrypt a message with private key, I can only decrypt with public key.

Encrypt with private key and decrypt with public key is infeasible in many cryptosystems, including those based on the Discrete Logarithm Problem, where public and private keys are fundamentally different. Encrypt with private key is also impossible in many implementations of RSA, and with many asymmetric encryption programs like PGP/GPG.

In an RSA encryption system, it is indeed can be mathematically defined how to to apply the encryption operation with the public exponent $e$ in the public key $(N,e)$ replaced by the private exponent $d$ from the private key. But if this heresy is performed, then anybody can decrypt with the original public key (which is public, see 6), and that goes against the primary goal of encryption. Don't do that.

In cryptosystems that perform signature rather than encryption, it is possible to sign a message with the private key, but that's not encryption. RSA can do both signature and encryption, but usual secure RSA-based signature and encryption cryptosystems have more differences than exchanging the role of public and private key.

  1. I can generate public key (derived key) from private key (base key).

Not in general. Cryptosystems based on the DLP indeed derive the public key from the private key (and the definition of the group, either public and fixed, or part of the private key). But that applies less to RSA.

  • In RSA as in the original article, the private key can be considered to be $(N,d)$, where $d$ is chosen essentially at random. It is impossible to find the public key $(N,e)$ from the private key $(N,d)$ alone (for proper choice of $N$): it is also needed the factors of $N$, which are not necessarily part of the private key.
  • In modern RSA, it is typically first chosen a small public exponent $e$, then drawn secret random prime factors $p,q$, forming $N=p\,q$, with $(N,e)$ the public key. Only then is the private exponent $d$ and the rest of the private key derived from $e,p,q$. So part of the private key is derived from data including a part of the public key.

What always holds it that a public/private key pair is derived from secret base data (output by a Random Number Generator), but the details of that derivation depend on the cryptosystem.

  1. I can not generate private key from public key.

True. Generating a private key matching a given public key would be a total break of any asymmetric cryptosystem.

  1. Private key name comes (from) how I handle the key: I keep it in secret, so I call it private key.

True. Notice that secret key is preferably reserved to symmetric cryptography, where the secret key is shared between cooperating parties; and private key is used for asymmetric cryptography, and assumed a secret that is not shared with anyone unless otherwise specified.

  1. Public key name comes (from) how (I) handle the key: I publish it, anybody can use it, so this is the public key.

True. There typically are additional differences beyond naming. That's the case with DLP, and often in RSA.

  1. If I publish the base key, I can call it public key.

No. The base key should not be published, if the base key is the private key, or is the secret base data that was used to generate a public/private key pair. Doing so would make the key pair useless, by revealing the private key matching the public key. Private keys must be kept secret, because knowledge of a private key allows to decipher, or forge signature.

  1. If I keep in secret the derived key, I can call it private key.

Not in general. In particular, not with DLP, where the "derived key" is bound to be the public key.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Regarding #3, can't you factor $N$ if you have $d$? $\endgroup$
    – forest
    Feb 25, 2019 at 7:39
  • $\begingroup$ @forest: one can factor $N$ given $N,d,e$. If the private key is $(N,d)$ with $d$ generated as in the original article, it is impossible to derive the public key $(N,e)$ from the private key, as in proposition 3, because we initially do not have $e$. $\endgroup$
    – fgrieu ♦
    Feb 25, 2019 at 7:46
  • $\begingroup$ You're right. I had forgotten that the original RSA picked $d$ more or less randomly. $\endgroup$
    – forest
    Feb 25, 2019 at 7:47
0
$\begingroup$
  1. Yes that's it!
  2. Never encrypt with your private key for secrecy! But you got the concept, your public key can reverse an operation done with your private key. That's basically how some signature works (take RSA-PSS for instance); but not exactly, you need to take extra care to make it really secure. Keep in mind that signature and encryption are two different things. You can encrypt a signature with your private key in order to show data integrity.
  3. Yes that's how public key are generated, public and private key are always linked in some way (the process to create the public key is not always the same).
  4. Yes, if you could do it, your encryption scheme would be broken.
  5. Yes, it's a common practice to name it that way.
  6. Same answer.
  7. You refereed to your private key as the base key, so I will assume that you were talking about it in this point. You should never publish your private key. If you do so, both keys become useless.
  8. You refereed to your public key as the derived key, so I will assume that you were talking about it in this point. Keeping your public key for yourself is useless, but even if you do so, don't call it "private", it's confusing. Your public key will always be called public, whether or not your publishing it.

I tried to address all of your point clearly, fell free to ask for clarification or details in comments

Improve this answer
$\endgroup$
7
  • $\begingroup$ Never encrypt with your private key for the purpose of secrecy. But do encrypt a signature with your private key for the purpose of demonstrating data integrity. $\endgroup$
    – vrtjason
    Jan 25, 2019 at 15:00
  • 1
    $\begingroup$ Forgot to mention that point, I modified the answer accordingly, thanks $\endgroup$
    – Faulst
    Jan 25, 2019 at 15:05
  • 4
    $\begingroup$ Signatures being "encrypt with the private key and decrypt with the public key" is completely wrong: Besides the fact that signing is not encryption, how does this apply to most signature schemes, such as hash-based signatures, Schnorr signatures, etc. In many signature schemes, encrypting with either key is simply not possible. Please help us dispel this widely repeated but wrong concept, rather than reinforcing it. $\endgroup$
    – Ella Rose
    Jan 25, 2019 at 15:53
  • $\begingroup$ @EllaRose That wasn't my point, sorry if I didn't explained well enough, I modified my answer to clarify this point $\endgroup$
    – Faulst
    Jan 25, 2019 at 16:04
  • $\begingroup$ Another remark: if you can derive the public key from the private key then you can obviously not switch around the public and private keys; public keys have different properties. Usually the public key can be derived from the private key, but I could imagine schemes where the public key and private key are generated from the same parameters but derivation of the public key from the private key is impossible. I think the different mathematical properties of the public and private key could be highlighted some more. $\endgroup$
    – Maarten Bodewes ♦
    Feb 24, 2019 at 17:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.