9
$\begingroup$

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.

Improve this question
$\endgroup$
11
  • 2
    $\begingroup$ 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? $\endgroup$
    – mkl
    Commented Dec 9, 2012 at 17:39
  • $\begingroup$ You don't have to publish your private key to remove non-repudiation, you can simply use a MAC. See this $\endgroup$
    – Flimm
    Commented Dec 9, 2012 at 21:47
  • $\begingroup$ 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. $\endgroup$
    – mkl
    Commented Dec 9, 2012 at 22:11
  • $\begingroup$ Is there any way using asymmetric encryption that you can achieve what a MAC achieves: authentication without non-repudiation? $\endgroup$
    – Flimm
    Commented Dec 9, 2012 at 22:46
  • 1
    $\begingroup$ I doubt its possible using PGP, but you may want to take a look at Ring Signatures 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. $\endgroup$
    – Maeher
    Commented Dec 10, 2012 at 17:11

4 Answers 4

Reset to default
2
$\begingroup$

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.

Improve this answer
$\endgroup$
1
$\begingroup$

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.

Improve this answer
$\endgroup$
12
  • $\begingroup$ 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. $\endgroup$
    – Flimm
    Commented Dec 10, 2012 at 17:34
  • 1
    $\begingroup$ "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: en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange $\endgroup$
    – dchest
    Commented Dec 10, 2012 at 18:28
  • $\begingroup$ @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. $\endgroup$
    – AJ Henderson
    Commented Dec 10, 2012 at 20:41
  • $\begingroup$ @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. $\endgroup$
    – AJ Henderson
    Commented Dec 10, 2012 at 20:42
  • $\begingroup$ @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. $\endgroup$
    – AJ Henderson
    Commented Dec 10, 2012 at 20:45
0
$\begingroup$

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

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ 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. $\endgroup$
    – Flimm
    Commented Dec 12, 2012 at 9:25
  • $\begingroup$ 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? $\endgroup$
    – Flimm
    Commented Dec 12, 2012 at 9:29
-1
$\begingroup$

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.

Improve this answer
$\endgroup$
4
  • $\begingroup$ 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. $\endgroup$
    – Flimm
    Commented Dec 10, 2012 at 11:48
  • $\begingroup$ I downvoted this answer, because it does not distinguish correctly between a digital signature, a MAC and a hash. $\endgroup$
    – Flimm
    Commented Dec 10, 2012 at 11:54
  • $\begingroup$ I don't understand @Flimm, you downvote my answer but your comment contains the same information... $\endgroup$
    – GdD
    Commented Dec 10, 2012 at 11:59
  • $\begingroup$ Someone deleted my comment. $\endgroup$
    – Flimm
    Commented Dec 10, 2012 at 15:28

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.