7
$\begingroup$

In the article How Does the Blockchain Work? the writer makes the following statements:

Since only you should be able to spend your bitcoins, each wallet is protected by a special cryptographic method that uses a unique pair of distinct but connected keys: a private and a public key.

If a message is encrypted with a specific public key, only the owner of the paired private key can decrypt and read the message. The reverse is also true: If you encrypt a message with your private key, only the paired public key can decrypt it. When David wants to send bitcoins, he needs to broadcast a message encrypted with the private key of his wallet. As David is the only one who knows the private key necessary to unlock his wallet, he is the only one who can spend his bitcoins. Each node in the network can cross-check that the transaction request is coming from David by decrypting the message with the public key of his wallet.

Specifically this: If you encrypt a message with your private key, only the paired public key can decrypt it.

Is it true that you can encrypt a string with a private key and only the public key can decrypt it? I was aware of the reverse, obviously, but this just doesn't seem right.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
20
$\begingroup$

Indeed the text quoted is wrong; at the very least, by using incorrect vocabulary. That should be: if you sign a message with your private key, the paired public key can be used to verify the signed message's integrity and origin.

What small amount of truth there is in the original statement boils down to: in some asymmetric cryptosystems, including RSA¹ (but not including ECDSA used in bitcoin and many other protocols), the sign operation includes a step similar to a step used in encryption, except with the private key instead of the public key; and that's undone in the verify operation, which includes a step similar to a step used in decryption, except with the public key instead of the private key.

¹ And then not the variant of RSA most used in practice for performance reasons, which uses the Chinese Remainder Theorem in private-key operations. That has no equivalent for public-key operations, and uses the private key in a form that makes it not interchangeable with the public key. That makes the twist in the text quoted unworkable.

Improve this answer
$\endgroup$
7
  • $\begingroup$ Nitpick: RSA sign shares a substep with decryption, verify with encryption. $\endgroup$
    – SAI Peregrinus
    Commented Oct 1, 2020 at 13:50
  • $\begingroup$ @SAI Peregrinus: Your statement is simple and correct. But it does not parallel the text quoted in the question, which compares signing to encryption, and verify to decryption. Hence my carefully pondered wording which is the less hairy I managed to get that is correct and pairs things as in the text quoted in the question. $\endgroup$
    – fgrieu ♦
    Commented Oct 1, 2020 at 15:30
  • 1
    $\begingroup$ CRT is mostly a red herring. Even if you represent the private key as the public exponent, RSA can work functionally with inverted keys, but it's trivially insecure, since given a private key $(n,d)$ you can deduce the public key $(n,e)$ by guessing that $e$ is 65537 or 3. $\endgroup$
    – Gilles 'SO- stop being evil'
    Commented Oct 1, 2020 at 15:47
  • $\begingroup$ @Gilles'SO-stopbeingevil': I'm pretty sure we can generate an RSA keypair with two large private keys. $\endgroup$
    – Joshua
    Commented Oct 1, 2020 at 19:01
  • $\begingroup$ @Gilles'SO-stopbeingevil' : my point for a note introducing the CRT in the context of the question is: CRT is typically used for RSA decryption, yet it can't safely be used when doing an RSA signature verification step (even if the public exponent is huge, which can be as pointed by Joshua). Hence making a parallel between signature verification and decryption (as done by the text quoted in the question) fails not only for ECDSA, but also for RSA as practiced. $\endgroup$
    – fgrieu ♦
    Commented Oct 1, 2020 at 19:17

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.