There's been an interesting (and somewhat heated) discussion (or debate) on the moderncrypto mailing lists recently, regarding the value of deniability in cryptographic protocols.
This discussion stems from the fact that deniability, as a feature of a cryptographic security protocol, does not necessarily come for free (more so in channels involving more than 2 people). It involves design and technical effort (and everything that comes along with that), as well as, generally (again more so with more than 2 participants), extra computational work and added complexity in the protocol.
The question that was asked was, given the extra effort required to incorporate deniability as a feature of a protocol... Is it worth it?
This resulted in a lot of back and forth, with people on both sides of the fence.
And my conclusion, after participation in this thread, is that there is confusion about what deniability is, and what it actually achieves. People think it does (or attempts to) do more than it actually does. Almost certainly a key part of this is how OTR advertised itself when it came to fruition. In essence people were under the impression that this new feature would allow you to deny your chat logs more easily, for example in court. Wrong.
Lets start off by looking at what deniability actually achieves...
When communicating with someone over an encrypted channel, it's not too far fetched to want to be able to ensure that the person you're speaking to is actually sending you the messages you are receiving, and that they are not being modified. This is Authenticity, and it is very important. Traditionally, (for example with PGP), this has been done by the use of asymmetric signatures.
Now there's a subtle problem with signatures, and that is not only does the person you are sending the message to have undeniable cryptographic proof that you wrote that message, but they could choose to show that message to anyone else, and they equally would have undeniable proof that you wrote the message.
Note: this is of course modulo your private key getting stolen.
This is the problem that deniability solves. You want cryptographic authenticity for messages you send to someone, but you only want that single person to be able to authenticate messages. They can still claim to other people that you said something, they just no longer have cryptographic proof.
The way this is done, at a very basic level, is thanks to the use of a "handshake" before any messages are sent, such that any message on the channel is undeniably either from you, or the person you are communicating with. And if you receive a message you haven't written, which is from either you or the other person, then it is undeniably from the other person.
So as it currently stands, these are the only two methods we have of having cryptographically authenticated communication:
- Using signatures of some sort (or something as cryptographically useful).
- Baking deniability in to the protocol.
In other words: deniability is not a new feature of communication protocols in general. If a cryptographic protocol has deniability, all it means is a property that has existed in every non-end-to-end encrypted protocol since the beginning of time also applies to this one.
Put bluntly, deniability will probably not protect you any more in court than if you had just been using Google Hangouts (or any 3rd party, non E2E encrypted messaging service where it is unlikely they would use server logs as evidence).
Why? Well, obtaining logs from a computer (or any other device), will still hold up as evidence in court as well as it has always done, we've never needed cryptographic evidence before. The person you are communicating with can still "betray" you and submit chat logs.
So is there any point in deniability, given that it probably won't help you in court at all, well yes actually, for what I consider 2 main reasons:
- Deniability maintains a property that has always existed in communications protocols, which means that there is no extra cognitive load required for a general user to use the protocol. Contrast that to PGP (the king of usability, hah), whereby to have authenticity, you need to sign every message, and the consequences of doing so are not at all clear to the end user. A choice between deniability and authenticity with my emails? I'd rather not want to force users to make that decision.
- We haven't had enough cases in court where cryptographically signed messages have been used as evidence, but they certainly will not be weaker evidence than their crypto-less counterparts. Almost certainly, a PGP signed email would be stronger evidence than an unsigned one, just as a signed instant message would be stronger evidence than a signed one.
To quote myself from the mailing list (yes there are typos):
We've been thinking the goals of what we're trying to achieve with deniability all wrong.
Deniability is the goal of trying to make our use of encrypted messaging not make us more liable for what we say any more than messaging has already done for years.
Deniability is NOT the introduction of a new property to our online messaging that allows us to be able to deny what we've said any more than we've been able to to in all our years previously without end to end encryption.
All deniability is, is putting safeguards in place so that our use of cryptographically secure communications protocols does not screw us over, and come with any more hidden surprises than any insecure communications protocol.