+1. What even is the use-case for plausible deniability? The way I heard it, is if your conversational partner is from the FBI and you want to whistleblow something, the plausible deniability can be used to plausibly deny that you said something to the agent. But who's the judge going to believe: the agent that claimed message X was sent to them, or the user who said that the agent must have forged message X? 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. The feature requires extra complexity in security protocols, plus might give people a false sense that they can just deny anything afterwards when that is not the case.
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...).
The main advantage of deniability is that it makes the encrypted messaging model more similar to the non-encrypted messaging model. Without encryption, if Alice sends Bob a message, a third party who later gets access to Bob's device (but who was not present at the time the message was sent) cannot know whether Alice really sent that message, or it was a forgery from Bob. With encryption but without deniability, a third party can prove that Alice sent that message, even years after the fact. With deniability, the original property is restored: anyone who can read a message can also forge it.
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).
> a third party [...] cannot know whether Alice really sent that message, or it was a forgery from Bob
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.
I misunderstood what you meant, I wasn't intentionally changing your meaning. Sorry for that.
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.
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...).