My original proposal was an adaptation of the Signal protocol for Nostr. https://github.com/nostr-protocol/nips/blob/2169fab971591d0b4a450ef08aeb6301c5d2a0da/104.md
But I got lots of feedback on that one that 1) group messaging needs to be first class and 2) multiple device support needs to be first class. Both of these are actually the same thing - supporting groups.
With the signal protocol, the way that the symmetric encryption works, when you're in a group, you're effectively creating a DM to every member of the group, encrypting it separately, and sending it out. Signal makes this feel like less of a big deal because they do some tricks on the server side to make it less heavy for the client.
In the nostr version of the signal protocol, you have no server to do work for you, so your device has to do all that work itself.
With MLS, because it's using a different data structure (binary trees) for managing encryption keys and users in a group, you go from a situation where group scaling is a linear problem (each new user in a group adds the same amount of work for all clients) to a log problem (where each new user in a group adds wayyyy less work for all clients).
There are also other benefits of MLS.
1) it's about to be an internet standard (like TLS, etc) so we conceivably get interoperability with other networks/clients
2) it's built to allow for the use of multiple ciphersuites and the graceful change/upgrade of the ciphersuites over time.
The only drawback is that it's very complex and very new. My work so far on getting MLS to Nostr has been focused on updating dependency libraries to allow for support of schnorr signatures over the secp256k1 curve (what nostr - and bitcoin - uses). I'm very convinced this is the right long-term solution for private messaging on Nostr but it's going to take a bit longer to get it probably ready for implementation.
If you haven't see it already, you can follow along with what I'm doing in my weekly posts. Also, if you're interested in working with me on all this, that'd be awesome.
This is the fourth in a series of weekly updates detailing progress on bringing MLS protocol DMs and group messaging to Nostr.
Previous Updates
Progress this week
The dependency train continues to roll. This week I was in touch with the maintainers of both OpenMLS and the hkpe-rs library and have pushed my changes forward in both areas. I’ve also gotten closer to understanding the wire format and relay requirements for the NIP I’m working on.
To be honest, the progress feels pretty slow at the moment but I’ve seen this story often enough to know that I’m on the right track. To be clear, my goal here is do this right and make it as easy as possible for Nostr devs to implement MLS based messaging across all of Nostr. That necessarily requires ensuring that all the implementation libraries support the right pieces and that our NIP is clean and well thought through (no one likes a shed full of bikes).
HPKE-RS
My PR to add support for secp256k1 is moving. I’ve been adding tests this week and fixing a few issues. Once this is merged, I’ll update my
secp256k1-based library as well. One unfortunate roadblock has been a lack of solid test vectors - this has eaten some time.OpenMLS Nostr Crypto
I had a short call with the OpenMLS maintainer team this week and was able to clarify what I’m trying to do and how they see it fitting in best. I was also able to get a better idea about how clients will need to process incoming messages. One interesting highlight: Messages have to be processed in the right order. Otherwise it’s impossible to keep the ratchet tree in the correct state. My left-curve solution to this for now is to use both created at (as a dumb first pass at sorting) + a hash of the previous message content. This will give Nostr clients a simple way to double check that they have the messages in the correct order before they attempt to process them. Unfortunatley, this doesn’t do a good job accounting for messages that are missing. My guess is that this isn’t going to be a major issue, but I won’t have a clear idea until there is a working Nostr relay based demo.
The next steps in my code for OpenMLS is to refactor the ciphersuites trait to make it easier to use custom ciphersuites. My initial PR hardcoded our secp256k1 based suite into the library but the clearly better solution is to refactor a few things to make sure that there isn’t any hardcoding in the main OpenMLS library, the ciphersuite, or the credentials (which hold your identity information and make prekey bundles possible). The library’s maintainers are open to this, so I’ve started on that this week.
Request for feedback
I’d love to hear from devs on one point. The OpenMLS library currently makes it very easy to serialize messages (both group control messages and actual messages between users). These messages have a lot of data in them about the current structure of the ratchet tree and whatever message or control event they’re trying to communicate. My current plan is to simply NIP-44 encrypt those serialized messages into the content field of a new event kind. The messages themselves are deserialized and processed in two simple calls by the OpenMLS library so I don’t see any reason to keep destructured or deserialized data in the nostr events that are heading over the wire. This also makes it easier to keep metadata about messages hidden to observers.
Goals Recap
It’s been a few weeks since I’ve talked about why this is important so, it’s time to recap what we’re aiming for:
- Private and Confidential DMs and Group messages
- Private means that an observer cannot tell that Alice and Bob are talking to one another, or that Alice is part of a specific group. This necessarily requires protecting metadata.
- Confidential means that the contents of conversations can only be viewed by the intended recipients.
- Forward secrecy and Post-compromise security (PCS) in the case of any key material being leaked, whether that’s your main Nostr identity key (your nsec) or any of the keys used in the MLS ratchet trees.
- Forward secrecy means that encrypted content in the past remains encrypted even if key material is leaked.
- Post compromise security means that leaking key material doesn’t allow an attacker to continue to read messages indefinitely into the future.
- Scales well for large groups. MLS provides this from a computational standpoint, but we need to make sure this works in a scalable way when multiple relays are involved.
- Allows for the use of multiple device/clients in a single conversation/group. Importantly, we’re not aiming to enable a device/client to be able to reconstruct the full history of a conversation at any point.
Onward and Upward
Grind, grind, grind. Touch grass & hug family. I’m visiting family starting next week for a few weeks. I’m going to be taking some time off in there so expect a few light updates in the coming weeks.