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

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