Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
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?
Consider the following system involving a message authentication code like HMAC-SHA256:
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:
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
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.
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.
