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
X (formerly Twitter)
SimpleX Chat (@SimpleXChat) on X
@JefferysKee @startpage That "PCS and Deniability are not very practically beneficial properties" is a view that most security researchers and tech...
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:
๐.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.
