9

The difference between a digital signature and a MAC is non-repudiation. A message with a digital signature proves that only the sender could have signed the message, whereas a message with a MAC proves that either the sender or the recipient could have signed the message.

Can an OpenPGP implementation, such as GPG, be used to sign a message without providing non-repudiation?

Please note that I am referring to non-repudiation in the cryptographic sense, not in the legal sense.

F1Linux
  • 273
  • 6
  • 12
Flimm
  • 2,758
  • 4
  • 15
  • 17
  • 2
    What remains in an electronic signature if you take non-repudiation from it? Ok, you can publish your private key. that way you drop non-repudiation, but what is a signature with that private key worth then? –  Dec 09 '12 at 17:39
  • You don't have to publish your private key to remove non-repudiation, you can simply use a MAC. See this – Flimm Dec 09 '12 at 21:47
  • If you use MACs, yes, but you asked about electronic signatures, didn't you? As far as i know, pgp uses asymmetric encryption. From here simply follow the article you referred to. –  Dec 09 '12 at 22:11
  • Is there any way using asymmetric encryption that you can achieve what a MAC achieves: authentication without non-repudiation? – Flimm Dec 09 '12 at 22:46
  • What, on a technical level, is the difference between authentication and non-repudiation? –  Dec 10 '12 at 06:34
  • Yes, there is a difference between authentication and non-repudiation. – Flimm Dec 10 '12 at 12:46
  • Yes, I forgot to say "in the context of electronic signatures, using public-private key pairs". –  Dec 10 '12 at 12:57
  • That's what I want to find out. – Flimm Dec 10 '12 at 12:58
  • As long as the private key used for the signature has not been shared and the algorithms used can be considered strong enough, the signature unambiguously indicates the private key holder as signer. Non-repudiation. OTOH I don't know whether there are any OpenPGP implementations which also offer some MAC-mechanism; thus, I cannot answer your question as it is formulated. ;) –  Dec 10 '12 at 13:07
  • 1
    I doubt its possible using PGP, but you may want to take a look at Ring Signatures http://en.wikipedia.org/wiki/Ring_signature

    They allow you to sign in such a way, that anybody in a group of your choosing (but nobody else) might have computed the signature.

     – Maeher Dec 10 '12 at 17:11
  • It is not really clear what your security goal is. For a signature, it is normally assumed to include non-repudiation. Do you want something like Alice knows that only herself or Bob could have created this message (and thus she knows that is was Bob, as she knows she didn't do it herself, but can't prove it to anybody else), like a MAC, without previously sharing a common secret? – Paŭlo Ebermann Dec 10 '12 at 20:46

4 Answers4

2

Yes, there's an indirect way to perform what's asked with PGP and variants.

Draw a an asymmetric public/private key (of a type that can sign), protected by a passphrase. Publish the passphrase-protected private key. Discard the public key (it's in the private key anyway). Use the passphrase as you would use a symmetric key: share it by trusted means between sender and receiver (perhaps together with the passphrase-protected private key). Generate, transmit and verify a detached signature (sig file) of a file to integrity-protect as you would do for a MAC of the file.

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

With asymmetric cryptography, the sender is not able to encrypt it such that the receiver could have encrypted it without disclosing a private secret without performing a symmetric key exchange. Once you exchange a symmetric key however, you could symmetrically encrypt the contents of the message and the MAC and then encrypt the shared key with the public key of the recipient. It is then impossible to prove that the message was signed by the sender since either party could have encrypted the message and MAC. I'm not sure if this can be done by the specific library implementation you mentioned though.

That said, I'm not sure why you changed from asking if PGP could do it to asking if asymmetric cryptography could. PGP makes use of both forms of cryptography.

AJ Henderson
  • 239
  • 2
  • 6
  • Your solution would be to pass Encrypt(symmetric_key, (message, mac)) and Encrypt(public_key, symmetric_key) to the recipient. How does this provide authentication? Surely, any attacker could form this pair of cipher-texts. – Flimm Dec 10 '12 at 17:34
  • 1
    "With asymmetric cryptography, the sender is not able to encrypt it such that the receiver could have encrypted it without disclosing a private secret." This is incorrect: http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange – dchest Dec 10 '12 at 18:28
  • @dchest - Diffie Hellman key exchange is not using Asymmetric crypto to provide the service I was talking about, it was providing an agreed upon symmetric key which can then be used by both parties to exchange data. By definition, asymmetric cryptography means that only the private key holder can decrypt information encrypted with the public key and only the holder of the private key could encrypt data such that it is decryptable by the public key. Thus, it is not possible for the receiver to produce an asymmetric validation that they could have been the sender as they lack the private key. – AJ Henderson Dec 10 '12 at 20:41
  • @dchest - What is possible is to exchange messages via asymmetric cryptography that allow for the secure establishment of a shared key. Anything that is shared on that shared key will then be known to be between those two parties, but the originator can not be proven as both parties have the shared secret. – AJ Henderson Dec 10 '12 at 20:42
  • @Flimm - The symmetric key is signed by the private key of the sender. You are talking about wanting a key exchange in your question. If you limit your asymmetric cryptographic operations to only the key exchange, then the payload can not be proven to be from either party since the only encryption on the information was exposed to both parties. Since the key exchange was signed by the sender and encrypted to the receiver's public key, no third party can have access to the shared secret key. – AJ Henderson Dec 10 '12 at 20:45
  • @Flimm - put more briefly, Encrypt (public_key, symmetric_key) is incomplete. It is Encrypt(public_key, Sign(private_key, symmetric_key)). Thus all that can be proven directionally is that sender sent a key to recipient. – AJ Henderson Dec 10 '12 at 20:47
  • @AJ Henderson - That would provide non-repudiation, which is an undesired property. The recipient can pass Encrypt(symmetric_key, (message, mac)) and Encrypt(public_key, Sign(private_key, symmetric_key)) to a third party, and the third party can be confident the message originated from the sender, since the recipient could not have forged it. – Flimm Dec 10 '12 at 20:54
  • @Flimm - Incorrect. The only thing that can be non-repudiated is the providing of the shared key. A third party can not tell if the sender or the receiver performed the symmetric encryption since it is not reliant on any secret of the sender. In other terms, it only proves that sender talked to recipient at some time. – AJ Henderson Dec 10 '12 at 20:56
  • @AJ Henderson: you're right. Thanks for the explanation! – Flimm Dec 10 '12 at 21:05
  • @AJHenderson DH is not asymmetric encryption, but it's an asymmetric algorithm. If we have two classes -- symmetric and asymmetric, where would you put DH? Certainly not symmetric. – dchest Dec 10 '12 at 21:12
  • @DChest - I'd classify DH as asymmetric, but any part of DH mutually attests to the sender and recipient. The only thing DH provides that isn't non-repudiative is the shared key which is used by a symmetric algorithm. I do think I see where you are coming from though if you assumed I was taking a looser definition of asymmetric vs symmetric. I have updated my answer to provide further clarification on this point. Thanks. – AJ Henderson Dec 10 '12 at 21:20
  • @AJHenderson thanks, the answer looks more clear now. – dchest Dec 11 '12 at 10:09
0

There's no way in OpenPGP to MAC a message. You can sign it, but that's it.

We could have a lively debate about the legal ramifications of a digital signature, and I'll take the side that it means less than you've been told it has. Like everything, context matters. I could give you a use case where there'd be an approximately 100% likelyhood that a digital signature would be "legal" and another where there'd be about zero. In the latter case, it could in contrast be evidence that the keyholder was hacked.

However, there is a feature of OpenPGP that might give you something like what you want. That is the Modification Detection Code. MDCs are on by default for any encrypted message these days.

The MDC is a subtle thing. When we (the working group) did it, we wanted a way to know that a message was intact, but not have to sign it. That is, the message is repudiable, but reliable (to some extent).

The problem arises from the fact that CFB encryption can be tail-truncated with impunity. In other words, if you get an unsigned OpenPGP message, you can never know that something wasn't removed from the end. (CBC mode has a related feature that it can be head-truncated with impunity.)

The MDC code puts a hash of the message at the end and encrypts it as usual. There are a few things to note about this:

  • We did it before there was a lot of theory about where a MAC ought to be placed. Present accepted practice is that you MAC the ciphertext, not the plaintext.

  • There are known "attacks" against this. Most notably, you can create an "existential forgery" of a message. This is really important with something like IPsec or TLS, but for OpenPGP is mostly a yawn, as it's a higher level concept. Spam is an existential forgery, for example.

  • The lack of reliability is a feature, given what the working group wanted. Remember, if you want a message to be intact, you can sign it. Heck, you can create a one-time signing key and sign it with that, if you're worried about legal etc. ramifications. Keys are cheap. What we wanted was a repudiable message that the receiver had a good chance to know arrived intact. It meets this goal. It fails to meet things that weren't goals for the feature, and frankly, my opinion is that you should just sign the message. As I said before, create a new signing key if you don't want tracking.

I think this is very close to what you want. It's not a MAC, it's less strong than a MAC. But it provides a reasonable level of assurance that the obvious CFB flaw hasn't happened.

Jon

Jon Callas
  • 2,304
  • 15
  • 13
  • 1
    If understand correctly, an MDC provides some level of integrity, but not authentication. After all, even with an MDC, an attacker could just use the recipient's public key to create a new encrypted message. What I'm asking for is authentication without non-repudiation. I realise the non-repudiation OpenPGP offers isn't good enough for court, but it could be good enough for another OpenPGP user. – Flimm Dec 12 '12 at 09:25
  • If the sender uses a one-time signing key, how would this provide authentication at all? How would the recipient know that the one-time signing key is associated with the sender's validated master signing key? – Flimm Dec 12 '12 at 09:29
-1

Authentication is the process of providing assurance that a data has not been tampered with, whereas non-repudiation demonstrates that the message is from a the holder of a particular private key. In general hash methods are used to provide authentication. Signing data with a private key provides non-repudiation whether you like it or not.

If you want to send a message in a way where it can be authenticated, but not linked back to yourself then hash the unencrypted message. If the recipient has pgp or something like it you can encrypt the message and its hash with the recipient's public key.

GdD
  • 119
  • 3
  • A digital signature proves that the message has been signed by the holder of the signature key, this proof can be passed to a third party, such as a judge. A MAC proves that the message has been signed by either the sender or the recipient, the recipient can not pass it to a third party to prove that the sender signed the message, since the recipient could also have generated the MAC. A hash proves that the message has not been modified assuming that the hash has not been modified, but it does not provide authentication, since anyone can create a hash. – Flimm Dec 10 '12 at 11:48
  • I downvoted this answer, because it does not distinguish correctly between a digital signature, a MAC and a hash. – Flimm Dec 10 '12 at 11:54
  • I don't understand @Flimm, you downvote my answer but your comment contains the same information... – GdD Dec 10 '12 at 11:59
  • Someone deleted my comment. – Flimm Dec 10 '12 at 15:28