Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] New Client Authentication Protocol #583

Open
s-rah opened this issue Jul 11, 2018 · 0 comments
Open

[Proposal] New Client Authentication Protocol #583

s-rah opened this issue Jul 11, 2018 · 0 comments

Comments

@s-rah
Copy link
Member

s-rah commented Jul 11, 2018

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:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant