7

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?

CodesInChaos
  • 24,841
  • 2
  • 89
  • 128
nkint
  • 167
  • 1
  • 1
  • 5
  • 2
    What you're looking for is called a digital signature. https://en.wikipedia.org/wiki/Digital_signature There are various frameworks that provide it on whatever platform you need. – Rob Napier Jul 26 '16 at 15:18
  • 1
    "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? – Artjom B. Jul 26 '16 at 19:08
  • 6
    "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? – poncho Sep 13 '16 at 03:55

4 Answers4

10

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.

Squeamish Ossifrage
  • 48,392
  • 3
  • 116
  • 223
1

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.

fgrieu
  • 140,762
  • 12
  • 307
  • 587
-1

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

Meir Maor
  • 11,835
  • 1
  • 23
  • 54
  • 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. – Squeamish Ossifrage Mar 10 '19 at 15:13
  • 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. – Meir Maor Mar 12 '19 at 04:31
  • OAEP is for encryption, not signature. – Squeamish Ossifrage Mar 12 '19 at 15:05
-6

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.

SEJPM
  • 45,967
  • 7
  • 99
  • 205
Ian Boyd
  • 1,001
  • 12
  • 14
  • 2
    The image seems to be taken from here without attribution. Anyway, there are multiple things that can be improved in this scheme. – Artjom B. Jul 26 '16 at 19:14
  • Thanks for not naming any of them. And public domain images need no attribution. Source: the link you linked to – Ian Boyd Aug 06 '16 at 02:48
  • so when using asymmetric encryption like in RSA, should you encrypt the message with the receivers public key and then sign the result with your own private key, so that the receiver can verify it by using your public key? – microwth Sep 13 '16 at 08:57
  • @microwth Technically you encrypt the message with a random key using symmetric encryption (e.g. AES). You then encrypt the random session key with the recipient's public key. Signing does involve your private key; but you don't sign the encrypted message - you encrypt a hash of the encrypted message. All this extra work (encrypt the key rather than the message, sign the hash rather than the message) is because RSA is horribly slow and inefficient. So you only have to encrypt a 16-byte key, and let super-fast AES do the real encryption. – Ian Boyd Sep 13 '16 at 17:29
  • 2
    “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. – Gilles 'SO- stop being evil' Oct 13 '16 at 20:55
  • @Gilles Encypting with an RSA private is signing. – Ian Boyd Oct 13 '16 at 22:40
  • Everyone has been puzzled by "I also need to be the only one that can understand integrity and authenticity". Does it means that what is wanted is to have n>1 things that each hold a key, prepare messages deemed as authentic by virtue of being authenticated using their key, and send the authenticated messages to a central system, which needs to be the only party that can verify the authenticity of a message? If yes, can the key held by each thing be assumed known and assigned by the central system. – fgrieu Oct 14 '16 at 07:55
  • 3
    @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. – Gilles 'SO- stop being evil' Oct 14 '16 at 10:05
  • I think we're at some kind of language barrier: "Encrypting with RSA private is* sigining"* "No, that is signing". No it is signing? "Two plus two is* five"* "No, two plus two is five" – Ian Boyd Oct 14 '16 at 19:20
  • 2
    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. – Maarten Bodewes Oct 15 '16 at 19:49
  • @zap Except when i'm the author. It's my image. I created it. And not only do i not need to attribute myself. – Ian Boyd Oct 17 '16 at 20:58
  • @IanBoyd Point well taken! – zaph Oct 17 '16 at 20:59
  • @MaartenBodewes For a real-world example of encrypting a hash with the senders private key, consult RFC4880 - OpenPGP message format. You hash the message, and encrypt that hash with your own private key. Anyone with your public key can then know that it was the owner of the private key who generated the signature. – Ian Boyd Oct 17 '16 at 21:08