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

Awesome Rust Cryptography: Should Double Ratchet algorithms be added to the Transport Encryption Libraries section #92

Open
potto216 opened this issue Sep 20, 2024 · 6 comments

Comments

@potto216
Copy link

Should Double Ratchet algorithms and other secure message exchange algorithms be added to the Transport Encryption Libraries section? Besides the Signal Rust code for the Double Ratchet algorithms the two most active crates I've found are:

  1. double-ratchet-signal v0.1.3
  2. double-ratchet-rs v0.4.6
    Neither appear to have been audited.

Thanks, Paul

@tarcieri
Copy link
Contributor

I'd think of them more like E2EE messaging libraries. We don't have a section for that but there are many things we could potentially put under there if we did.

@potto216
Copy link
Author

I also think messaging libraries would be a valuable section, especially for investigating solutions for low data rate wireless messaging systems where post quantum algorithms' larger data requirements may require a suite of options.

What would the next step be? Work with others on defining the section?

@tarcieri
Copy link
Contributor

If you want to add a messaging section, it might be helpful to enumerate other mature messaging-related libraries, like OpenMLS

@potto216
Copy link
Author

Okay great, I'll work on that this week and submit a PR with edits to https://github.com/The-DevX-Initiative/RCIG_Coordination_Repo/blob/main/Awesome_Rust_Cryptography.md unless there is a different procedure.

@potto216
Copy link
Author

@tarcieri what are your thoughts on the following?

Secure Messaging Protocols

This section is for secure messaging protocols that share the common properties of transferring messages in a framework with end-to-end encryption (E2EE) perfect forward secrecy, and post-compromise security. The algorithms I would include (assuming I can find the Rust implementations) are:

  • Signal protocol: Used in applications such as WhatsApp, Signal. The protocol uses the Double Ratchet algorithm for confidentiality and integrity along with perfect forward secrecy, and post-compromise security. Also supports authentication with Extended Triple Diffie-Hellman handshake.

  • Off-the-Record (OTR): an early secure messaging protocols that provides encryption, authentication, deniability, and forward secrecy. It was widely used in instant messaging clients before protocols like Signal.

  • Messaging Layer Security (MLS) RFC 9420: designed for secure group messaging with forward secrecy, post-compromise security, and deniable authentication.

  • Matrix’s Olm/Megolm: a decentralized secure messaging protocol used by Matrix. Olm is used for one-to-one messaging, while Megolm handles group messaging.

  • Matter protocol: Although this is for IoT devices it is a secure application layer message protocol that supports encryption, authentication, and privacy.

I would not include connectionless VPN protocols like [WireGuard] (https://www.wireguard.com/protocol/) or underlying protocols like Noise.

I'm not sure about secure protocol pairs like the Constrained Application Protocol CoAP using Datagram Transport Layer Security [DTLS] (https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security) for end-to-end security. It is message like with its RESTFul interface but CoAP requires an underlying protocol to be secure.

@tarcieri
Copy link
Contributor

This resource is a list of Rust crates/libraries that implement protocols, not just a generic overview of protocols.

So it should be e.g. OpenMLS and mls-rs, not just information about MLS as a protocol

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

No branches or pull requests

2 participants