I need a way to protect my data.

More then encryption I need a way to guarantee integrity and authenticity but I also need to be the only one that can understand integrity and authenticity.

I found HMAC to be a good way for integrity and authenticity but it is based on a single key that I should share within my software and I don't like it.

Is there a something like HMAC but with public-private key so that I can share only one key?

  • 2
    $\begingroup$ What you're looking for is called a digital signature. en.wikipedia.org/wiki/Digital_signature There are various frameworks that provide it on whatever platform you need. $\endgroup$
    – Rob Napier
    Commented Jul 26, 2016 at 15:18
  • 1
    $\begingroup$ "but I also need to be the only one that can understand integrity and authenticity." - Yes, with HMAC. In public-key signatures, the public key is supposed to be public so this requirement cannot be achieved. Can you clarify what you mean by that requirement? $\endgroup$
    – Artjom B.
    Commented Jul 26, 2016 at 19:08
  • 6
    $\begingroup$ "I also need to be the only one that can understand integrity and authenticity"; what do you mean by that? Do you mean that you (the intended recipient) are the only one able to verify the integrity of the message? Who is encrypting the message; what keys do they have? $\endgroup$
    – poncho
    Commented Sep 13, 2016 at 3:55

4 Answers 4


Consider the following system involving a message authentication code like HMAC-SHA256:

  • Alice generates a key and shares it with Bob, and Bob alone.
  • Alice authenticates a message with the key.
  • Bob acts on the message only if it can be verified with the key.

Of course, Alice can verify messages too, and Bob can forge messages too. Indeed, anyone who has the key can verify or forge messages: the key necessarily grants the power to do both. Consequently, Alice can't present a cryptographic proof to a third party that a message came from Bob, because Alice could have forged the message; and vice versa. Thus this system has ‘deniability’, or lacks third-party verifiability.

Consider the following system involving a digital signature scheme like RSASSA-PSS or Ed25519:

  • Alice generates a key pair and shares the public key with Bob, and Bob alone.
  • Alice signs a message with her private key.
  • Bob acts on the message only if it can be verified with Alice's public key.

Only Alice can sign messages; anyone with the public key can verify them but not sign them. You asked that only Bob be able to verify messages. Can the public key be kept secret so that Bob alone can verify them?

The standard for signature security is existential unforgeability under adaptive chosen-message attack, or EUF-CMA, which means that an adversary who can query an oracle for the signature of any message of their choice nevertheless can't forge a signature for any message they didn't query the oracle for. Nothing prevents an EUF-CMA signature scheme from simply including a copy of the public key in the signature itself, so that won't keep Alice's public key secret.

There's a nonstandard property of some public-key cryptosystems called key privacy—formalized for public-key encryption schemes, it means that given two public keys and a ciphertext the adversary can't tell which public key the ciphertext corresponds to. Of course, this doesn't carry over naturally to signatures because if you had the public keys and message you could just verify the signature.

There's a related notion of anonymous signature schemes, where an adversary presented with two public keys and a signature but not the message can't tell which public key made it, which typical RSA-based signature schemes fail by the German tank problem to the chagrin of the Australian Department of Human Services who hoped it provided privacy it didn't. Schnorr-type signature schemes in a standard group like Ed25519 do tend to provide anonymity in this sense.

There's another related notion of key indistinguishability (paywall-free) where an adversary presented with two public keys and a signing oracle can't tell whether the public keys have the same private key, but this is in an exotic context where a set of many users can sign messages with their respective private keys, but only one party can distinguish signatures made by the users.

Which of these do you want? I don't know—it's not clear to me what you're trying to accomplish at a higher level, so it's hard to give more specific advice.


It seems to be asked a method to authenticate a message $m$ using a public key $\mathrm{pubk}$, so that a private key $\mathrm{privk}$ is necessary to make the verification.

That's not possible, because an adversary knowing $\mathrm{pubk}$ can apply the method to any message s/he chooses. More generally, public software without a secret/private key can't be used to authenticate data.

However, it is possible to authenticate $m$ using a secret key $\mathrm{sk}$ and public key $\mathrm{pubk}$, so that verification can be performed only using $\mathrm{sk}$ and $\mathrm{privk}$. One solution is to compute HMAC of $m$ using $\mathrm{sk}$, and encipher the result using $\mathrm{pubk}$ (e.g. per RSAES-OAEP), yielding the authenticator. Verification deciphers that authenticator using $\mathrm{privk}$, then verify the MAC.


As Rob mentioned in a comment you are asking for a public key signature scheme. en.wikipedia.org/wiki/Digital_signature

There are plenty of libraries implementing signatures end-to-end. But to explain a brief outline: hash your data, apply padding: https://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding sign with RSA private key(modular exponentiaion)

The verification is therefor: apply RSA public key remove OAEP compare with data hash

  • $\begingroup$ It's not signing (‘sign with the RSA private key’) if there's no hashing—hashing is an integral part of signing, not just a preprocessing step needed only to compress long messages, and in modern schemes like Ed25519 the hashing involves the private key itself. Also OAEP is not relevant to signature. No need to summarize the guts of how something like RSASSA-PSS works; I suggest you describe the properties that it gives: unforgeability and third-party verifiability. $\endgroup$ Commented Mar 10, 2019 at 15:13
  • $\begingroup$ I wanted to write something more than use a library it's a aolved problem. Though there are other options, I tried to outline a simple one. If you think I skipped a fundamental step to make this secure ppease comment. The first link I gave describes all relevant such properties. $\endgroup$
    – Meir Maor
    Commented Mar 12, 2019 at 4:31
  • $\begingroup$ OAEP is for encryption, not signature. $\endgroup$ Commented Mar 12, 2019 at 15:05

It's standard to encrypt the message digest with the private key - so that the receiver can verify with the public key that the message has not been altered.

enter image description here

What you can do, if you have a secret password in your head, is use your password as the HMAC key when computing the digest.

It's a bad idea, because it means you have to know your private password that only exists in your head in order to do the encryption.

  • 2
    $\begingroup$ The image seems to be taken from here without attribution. Anyway, there are multiple things that can be improved in this scheme. $\endgroup$
    – Artjom B.
    Commented Jul 26, 2016 at 19:14
  • $\begingroup$ Thanks for not naming any of them. And public domain images need no attribution. Source: the link you linked to $\endgroup$
    – Ian Boyd
    Commented Aug 6, 2016 at 2:48
  • 2
    $\begingroup$ “It's standard to encrypt the message digest with the private key” — absolutely not. You seem to be confusing signing with encryption. They are completely different things. $\endgroup$ Commented Oct 13, 2016 at 20:55
  • 3
    $\begingroup$ @IanBoyd No, that's signing. In the special case of textbook RSA, that's the same mathematical operation, but textbook RSA is not a valid way of encrypting or signing, it has plenty of algebraic weaknesses. For actual valid crypto primitives such as RSA-PKCS1.5 and RSA-OAEP/RSA-PSS, they are different operations. For most other asymmetric crypto algorithms, signing and encryption keys aren't even the same kind of mathematical objects. $\endgroup$ Commented Oct 14, 2016 at 10:05
  • 2
    $\begingroup$ Two plus two isn't five, and RSA encryption is not the same thing as signing. Besides that, encrypting a MAC value certainly isn't signing, and sending both the MAC value and the encrypted MAC value doesn't make sense either. $\endgroup$
    – Maarten Bodewes
    Commented Oct 15, 2016 at 19:49

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.