Improving repudiation (deniability) in SimpleX protocols

Please send any questions/comments!

We believe that repudiation (aka deniability) is very important for communications. See this discussion with Session CTO about it, for example:
https://twitter.com/JefferysKee/status/1754336020857029013
https://twitter.com/SimpleXChat/status/1754455524068720762 
https://twitter.com/JefferysKee/status/1754762787119919587
https://twitter.com/SimpleXChat/status/1754840209936543977

Currently only a part of SimpleX protocol stack provides it – client-to-client e2e encryption, that includes double ratchet (aka Signal) algorithm in one of the layers.

Client-relay protocol, on another hand, does not provide it, and as relays are chosen by the recipients, a modified relay can provide non-repudiation for sent messages, which is undesirable in the context of private communications.

We believe there should be a possibility for digital off-the-record conversations, in the same way as it is possible for in-person meetings - while recipient can keep the memory and even transcript, it should not be a strong proof to a third party.

This proposal adds repudiation to client-relay protocol by replacing cryptographic signature with authenticator (see this WIP document for the details: https://github.com/simplex-chat/simplexmq/blob/ep/cmd-auth/rfcs/2024-02-03-deniability.md).

It is already mostly implemented and will be fully rolled out by v5.7.

A more detailed post about repudiation importance and its acceptance in society and legal systems is coming.