You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would provide client authentication as well as offline deniability (not online deniability), and Tor would not break the deniability. An improvement over the current challenge-response protocol, and it would also give us protocol level encryption.
There have been discussions about this before e.g. #72 which tailored off with talk of axolotl and otr. I think there are still open questions about multi-party encryption and the like, but I don't think improving the standard two party authentication harms any future extensions.
Way back then @special outlined 3 considerations which I think are still good:
1) Any additional cryptography provides a clear benefit over what we have now
2) Applies to arbitrary protocol data, not just chat messages; e.g. file transfers
3) Implementation doesn't add an unmanageable security/exploitation risk
I think 3DH meets those 3 points.
In any case, OP will be implementing this (most likely as im.ricochet.auth.3dh-dake) in libricochet-go as we believe it provides a notable improvement to the current state. I think this would be a solid improvement to add this to the spec/application too.
The text was updated successfully, but these errors were encountered:
Today I had a conversation with someone regarding deniability and the way ricochet currently does client authentication in the protocol.
They proposed we replace our current challenge-response protocol (https://github.com/ricochet-im/ricochet/blob/master/doc/protocol.md#authhiddenservice) with a 3DH DAKE - we would then encrypt messages between peers using the derived key.
This would provide client authentication as well as offline deniability (not online deniability), and Tor would not break the deniability. An improvement over the current challenge-response protocol, and it would also give us protocol level encryption.
There have been discussions about this before e.g. #72 which tailored off with talk of axolotl and otr. I think there are still open questions about multi-party encryption and the like, but I don't think improving the standard two party authentication harms any future extensions.
Way back then @special outlined 3 considerations which I think are still good:
I think 3DH meets those 3 points.
In any case, OP will be implementing this (most likely as
im.ricochet.auth.3dh-dake
) in libricochet-go as we believe it provides a notable improvement to the current state. I think this would be a solid improvement to add this to the spec/application too.The text was updated successfully, but these errors were encountered: