3 ms·

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

by cesarb 6y ago

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).

lucb1e 6y ago
> 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.

by cesarb 6y ago

lucb1e 6y ago

> 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.