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.
Repudiation is usually considered a threat to information integrity.
If anyone wants to establish an agreement privately over simplex, this would make it one party’s word against another’s.
Is this for all simplex or a special mode the user can invoke? I would read the GitHub page to find out but it’s 404
You can always add a repudiation layer on top for your digital contracts etc. Just digitally signed stuff even offline maybe then send via SimpleX.
