The Messaging Layer Security (MLS) Protocol
datatracker.ietf.org
datatracker.ietf.org
https://mailarchive.ietf.org/arch/msg/mls/ZJ4e78obXSdYWnxmsN...
The Signal Protocol achieved deniability by using a three-way Diffie-Hellman handshake instead of digital signatures: https://signal.org/docs/specifications/x3dh/#deniability
I think we can do something similar. The Matrix folks are already working on a decentralized MLS, after all.
Checking Wikipedia to make sure I understand the point correctly, it claims it's more about denying that encryption was used at all (good luck with that one in an encrypted chat) or that there can be multiple plaintexts (so you can later come up with a completely different chat log, lying in court and claiming the other party has forged everything, which has the same issue as above).
Transcript consistency on the other hand seems to me like an expected feature for any >2010 multi-party encryption protocol. That can be practically used to change the conversation shown to a third participant (taking a "yes" of mine from one place, pasting it elsewhere while withholding the original reply...).
Even more important, a signed message without deniability keeps its signature even when it's moved outside its original context. If malware copies all the data from Bob's device, whoever controls it can ask for a ransom by threatening to reveal the signed message and prove it came from Alice; with deniability, they cannot prove that this message was not a forgery, either by Bob or by whoever revealed it.
That is, the interesting case is not when one of the parties is an "FBI agent"; deniability does nothing in that case, since the "FBI agent" can be assumed to not forge the message (and thus, by exclusion, it can only have come from the other party).
> Heck, if the government is that suspicious of someone they can also order the ISP to setup a tap and see that the right number of bytes at the right time were sent.
Setting aside that, unlike non-deniable encryption, this is not retroactive (a government cannot order a ISP to setup a tap in the past), the number of bytes sent reveals nothing about the message other than its size (and if padding is used, not even that).
But realistically, how often does Bob create and store forgeries of all of Alice's messages to protect her just in case his device gets hacked? This seems even less likely than the blackmail scenario proposed in a sibling thread and your second paragraph.
I'm not saying "let's not add features that are not absolutely essential" (I'm one of the people in favor of client-side hashing, which other security people seem to reject for having too small a benefit), but rather that I've seen the amount of complexity it adds and I just really can't think of scenarios that are plausible enough to be worth the potential false sense of security and added complexity in an already complex protocol. TLS is simpler and we see how many ways that got hacked. (Come to think of it, it is curious that I can name various old TLS/SSL flaws but not any in previous versions of OTR, Axolotl/Signal/Wire, etc. Protocol versions, that is; not implementations. But perhaps they're just publicized less.)
> unlike non-deniable encryption, this is not retroactive (a government cannot order a ISP to setup a tap in the past)
There are much simpler solutions to prevent retroactive proving. Barring just throwing away the chat log, the receiving client could discard the signature after verification. That maintains plausible deniability for the messages because there is no signature of Alice's and adds literally zero complexity to the protocol. That's just an idea I randomly came up with on the spot so perhaps it's really stupid for some reason, but why don't we just do that?
> if padding is used, not even that
This is about minor details now but, padding is at most as large as the block size and modern modes like GCM don't use padding at all. The protocol would need to mix in random garbage and limit the rate at which you can send bytes to prevent time and size correlation, which can otherwise both be independently matched against the chat log. Unless specifically thwarted with a sizeable amount of noise, traffic correlation is going to be possible. Correct me if I'm wrong but I would not expect any general purpose chat protocol in 2020 to consider this to be within its scope.
If it’s just a blackmailer or con artist, deniability is very useful.
Fair enough, but for any legitimate purpose?
If you are being blackmailed by someone, you would find it useful to be able to repudiate the compromat they are using.
Indeed, denying that you never said something that someone is blackmailing you about is useful. But you can deny it anyway. Have you ever heard of a criminal blackmailing someone saying "and I have your cryptographic signature to prove it"? The person that the criminal wants to prove it to would have to also be convinced that this public key is indeed yours. It's not an impossible scenario, but it does seem contrived.
However I know of people being afraid of being blackmailed based on things like text conversations, and whether or not it came down to a signature or not, plausible deniability was definitely a factor in how seriously they took the threat.
In my opinion the best article about it is: https://blog.trailofbits.com/2019/08/06/better-encrypted-gro...
For example, Joining a (n,n)-signature schema without a trusted third party.
Whether or not that's a "false" sense of privacy depends on your threat model.
Is your primary threat "What if someone hacks the communication server and leaks our conversations?" (This is something I worry about a lot.)
Is your primary threat "What if someone in our chat is a spy and we're planning crimes?" (This is something I don't worry about, but others might.)
In the first case, E2EE for up to 1000 participants in a group still makes sense.
In the second case, every additional participant is additional liability of government subversion.