5

I've read in some books the 'goals of information security', which includes non-repudiation.

My understanding of non-repudiation is that if Alice sends a message to Bob, Bob is not only convinced that the message came from Alice but he can also prove to Carol that the message indeed came from Alice (assuming Carol doesn't trust Bob)

Recently, while watching a talk of Moxie Marlinspike, I learned that non-repudiation is not necessarily a good thing (you might want to deny authorship of a message to the world), and hence he spent time to develop this new protocol (Axolotl) which has a thing called 'plausible deniability' which I assume is that if Alice sends a message to Bob, Bob can be certain that it came from Alice, but Bob cannot prove to Carol that it did actually come from Alice.

Now, to a beginner, those two ideas are kind of contradictory and hence the confusion and this question (and the following sub-questions).

  • Have the goals of information security changed?
  • Are there specific use cases where either of the two (non-repudiation and plausible deniability) is useful to have? (An example would help a lot)
schroeder
  • 123,438
  • 55
  • 284
  • 319
Abhishek Nagekar
  • 65
  • 7

2 Answers2

9

As in any other aspect of life, one might have different information security goals in different situations. There are situations in which you want non-repudiation and there are situations in which you would want plausible deniability. Likewise, there are situations in which you would want non-repudiation on some aspects but plausible deniability on others.

For example, let's say you've made a deal with someone and want to sign a contract with them. Such a contract would not be of much value if one of the sides of the contract could later deny signing it. Each of the sides to a contract wants non-repudiation on the other side's signature.

On the other hand, consider the case where you are a whistle-blower informing the authorities of some grave crime being committed by your employer and you're worried your employer may discover your leak. In this scenario you would want plausible deniability.

David Wachtfogel
  • 5,512
  • 21
  • 35
  • That makes sense. Thank you for clarifying it for me. I had assumed that it would depend on the usecase, but just wasn't sure and couldn't find supporting resources. – Abhishek Nagekar Aug 28 '17 at 15:43
6

It seems contradictory but it's not. One doesn't have to prove non-repudiation and plausible deniability at the same time. You can deny the ownership of the message while still keeping its authenticity or you can prove your authorship by digitally signing it. But you can't do both at the same time.

A specific use case is in Signalapp messaging protocol, it is possible to deny the ownership of the message in direct messages. Each message is appended with HMAC-SHA256 to verify the integrity of the cipher text. HMAC cannot be used to prove non-repudiation because the shared secret is known to both the sender and the recepient.

A recepient can prove the authenticity of the message that it is indeed sent by you. If it's not him who wrote the message then it must be you who wrote it. In either manner, both the sender and the recipient can verify who sent the message. But neither of them can prove authorship of the message to others. A recepient can easily forge HMAC with a valid key to make it look like sender has sent this. He can also give away the shared secret to a 3rd party to forge HMACs in future messages . Here you are providing plausible deniability.

But in group messaging like in WhatsApp which has an optimisation of Signal group messaging uses Signature keys. Each group participant signs the message with its private Signature key and everyone can verify that it is indeed you sending the messages and not someone else forging it. Here you are providing non-repudiation.

defalt
  • 6,231
  • 2
  • 22
  • 37