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.
simplex / SimpleX Chat
npub1ex…7d828
2024-02-07 13:06:37
Author Public Key
npub1exv22uulqnmlluszc4yk92jhs2e5ajcs6mu3t00a6avzjcalj9csm7d828Published at
2024-02-07 13:06:37Event JSON
{
"id": "51287c48b91ade4fb7e147482794a7df354ad3690965d695b481d8ca83542446",
"pubkey": "c998a5739f04f7fff202c54962aa5782b34ecb10d6f915bdfdd7582963bf9171",
"created_at": 1707311197,
"kind": 1,
"tags": [
[
"r",
"https://twitter.com/JefferysKee/status/1754336020857029013"
],
[
"r",
"https://twitter.com/SimpleXChat/status/1754455524068720762"
],
[
"r",
"https://twitter.com/JefferysKee/status/1754762787119919587"
],
[
"r",
"https://twitter.com/SimpleXChat/status/1754840209936543977"
],
[
"r",
"https://github.com/simplex-chat/simplexmq/blob/ep/cmd-auth/rfcs/2024-02-03-deniability.md)."
]
],
"content": "Improving repudiation (deniability) in SimpleX protocols\n\nPlease send any questions/comments!\n\nWe believe that repudiation (aka deniability) is very important for communications. See this discussion with Session CTO about it, for example:\nhttps://twitter.com/JefferysKee/status/1754336020857029013\nhttps://twitter.com/SimpleXChat/status/1754455524068720762 \nhttps://twitter.com/JefferysKee/status/1754762787119919587\nhttps://twitter.com/SimpleXChat/status/1754840209936543977\n\nCurrently 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.\n\nClient-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.\n\nWe 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.\n\nThis 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).\n\nIt is already mostly implemented and will be fully rolled out by v5.7.\n\nA more detailed post about repudiation importance and its acceptance in society and legal systems is coming.",
"sig": "a60d39c5ca466ceb527b71ff8dbc2cb1429ccfe4d5a10dfabb5df64302eb409a0a49a1ddaeed49c503524a25f5e2fb25e7674532158204b5f1d554104f6add05"
}