2

Is there a way where I can distribute a public decryption key, but the encryption key cannot be computed from that key, so that anyone who reads one of my encrypted message, he/she can be quite sure that it was originally written by me?

So basically it is the traditional asymmetric encryption-decryption scheme, but in reverse.

  • 3
    Of course, this is what is called a digital signature. Usually you do not encrypt the message itself but only a digest calculated from the message content, but appart from that it works as you described. – WhiteWinterWolf Jun 26 '16 at 12:02
  • @WhiteWinterWolf: Since that's the only sensible answer wouldn't it be better to put that as an answer? Otherwise the question ought to be closed or marked as a duplicate (if it is) – RedGrittyBrick Jun 26 '16 at 12:15
  • @RedGrittyBrick: This seemed a bit short to me to be put as an answer (you know, "link-only answers" and all that's stuff, you seem to be veteran on several SE sites so I suppose you get my point ;) ). Nevertheless, I found a relevant and possible duplicate thread here (the OP was aware of asymetric encryption but did not know how it fits with digital signature): Digital Signature and Verification? – WhiteWinterWolf Jun 26 '16 at 12:24
  • As CBHacking in his answer mentioned, you may need to both encrypt and sign, which is termed signcryption. For one way of doing that in RSA see Ex.3S of my code s13.zetaboards.com/Crypto/topic/7234475/1/ – Mok-Kong Shen Jun 26 '16 at 16:31
3

First of all, as @WhiteWinterWolf points out, this is a digital signature scheme. Digital signing is specifically for the purpose of making sure that the message is from you, not somebody else, and hasn't been modified since it was signed. Without going into the math, here's how it works:

You have a message that you want the world to know came from you
You have a public/private key pair that supports signing (RSA, DSA, etc.)
You take a cryptographic hash (usually something like SHA-256) of the message
 - Like asymmetric encryption, signing schemes work best on small bits of data
You create a digital signature of the hash digest (the output of the hash function)
 - This requires your private key
You distribute the message, the signature, and the algorithms (hash and signing) used
Alice has your public key, and wants to confirm that the message is authentic
Alice re-hashes the message, with the same scheme
Alice then uses your public key to turn the signature back into the hash digest
Alice checks if the digest of the message and the digest from the signature match
 - This is called verifying a signature

Cryptographic signatures are used all over. They're used in X.509 certificates (like SSL/TLS uses) to verify that the certificate was issued by a trusted authority, and hasn't been tampered with. They're used in secure email, to make sure that the recipient knows the sender of the mail wasn't spoofed. They're used with signed files, usually executable binaries, so that the author of the file is known. That's just a few of the common uses.


Now, with that said, let's be clear about something:

Encryption, in general, does NOT provide authentication (proof of the identity of the source of the message) or integrity (confirmation that the message has not been tampered with); only confidentiality (also called privacy or secrecy). If you encrypt a message, but don't sign it (or provide some other form of verification), an attacker can take the encrypted message and manipulate it, changing the meaning even though the attacker doesn't know what the original text was. The recipient of the message can then decrypt the message, and may have no idea it was tampered with.

For some stuff, this isn't very meaningful; an attacker tweaking English text that they don't know the content of will produce meaningless gibberish. For other things, though, it can matter a lot. Do not rely on encryption to verify where a message comes from! (Caveat: if using an "authenticated encryption" scheme, that includes integrity checks and, if nobody else has the key, also provides authentication. You shouldn't assume that encryption provides these things, though; most of the time it doesn't.)

| improve this answer | |
3

Others have already mentioned that it sounds like you're looking for a digital signature. There's another part of your question that is important: how to actually distribute your public key (which users will use to verify your signature).

A few common methods (in no particular order):

  1. Meet up in person with whomever you intend to send messages to, and give them your key (flash drive, printed on paper, etc.). This is quite secure, assuming others know what you look like but it's difficult/impossible to scale.
  2. Use some public key infrastructure to distribute your key. Anyone who wants your key can use the PKI to obtain your key. This generally scales pretty well. The typical example of a PKI is a certificate authority, which signs security keys for websites. There's a risk that if the PKI is compromised in some way, an attacker could get others to accept the attacker's public key as yours.
  3. Use a public key store. There are some more methods in this related question.
  4. If this is for a specific user application, you could hardcode your public key into the application.
| improve this answer | |
  • Please don't call it a "decryption key". Public keys are used for encrypting and for verifying, never for decrypting. The operation of signature verification may resemble decryption, but the purpose is completely different and they should not be confused. It is quite sufficient, and arguably more accurate, to simply say "your public key". – CBHacking Jun 26 '16 at 21:19
  • That's a good point, and I've updated my answer. My fault for copying too much verbatim from the original question. – Fishy Jun 27 '16 at 13:17

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