Oddbean

Some thoughts *before* I read the draft NIP. I think we should propose an #MLS cipher suite that uses secp256k1 and reserve an identifier for it. That way we it can use libsecp256k1. The secp256k1 curve can be used for both key exchange (xonly?) and (BIP340 schnorr) signatures. This curve is not yet listed under the recommended MLS Cipher Suites. By carefully picking the other parameters it may be easier for Bitcoin signing devices to keep your chats ultra secure. And if a nostr client is already using some Bitcoin related library, then it's great if it already has the required ciphers. Meanwhile rfc9420 has a mandatory-to-implement cipher suite MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519. This is useful for interoperability with other social networks, but that seems low priority to me compared to being simple to implement. And with respect to not adding more dependencies and not increasing the attack surface of cryptographic implementation errors. MLS supports switching ciphers for existing groups, so we can always add compatibility later. Or secp256k1-pill the other networks :-) For the hash function sha256 makes the most sense. For AEAD ChaCha20Poly1305 is used in BIP324 (encrypted p2p transport) as well as the Stratum v2 noise protocol. Not sure what to pick for the Key Encapsulation Mechanism (KEM), or maybe that's already covered by ChaCha20Poly1305? So CipherSuite name MLS_256_???_CHACHA20POLY1305_SHA256_Secp256k1. https://www.rfc-editor.org/rfc/rfc9420.html#mls-cipher-suites

I do not agree with this zero sum attitude towards developer attention. How do you steal something that is given freely? Nostr and bitcoin are built on voluntarist principles. Naturally, some of the same people take an interest in both networks. Ensuring private, secure, and free speech is not less important than private, secure, free money.

It looks like @JeffG's current NIP proposal doesn't go into detail yet about the choice of ciphersuites. It does consider many other aspects of how to integratate this with Nostr. So that's next on my reading list. https://github.com/nostr-protocol/nips/pull/1427

Hey @provoost! Thanks for taking the time to write this up. I was thinking the exact same thing. I have been in touch with various MLS folks (both those working on the spec but also those working on the OpenMLS implementation). They are open to the idea and suggested that we create it as a custom ciphersuite so we don't have to wait on IANA to give us an identifier. For now, I'm more concerned with getting the rest of the NIP finalized and implementing it with the default ciphersuite to make sure that we have a working solution. As you say, we can deal with the custom ciphersuite later and upgrade groups.

I suppose that for a prototype the default-mandatory ciphersuite is fine. But I would hold off on finalizing the NIP until we have custom ciphersuite. Otherwise every Nostr client out there starts pulling in random dependencies from all over the internet. ... (well that might happen anyway, because you can't stop people as soon as a prototype works)

I also don't think there's much of a rush. Once there's an "official" number assigned, we recommend that clients use it. But until then the private usage number is just fine. What is most useful I think is to have more eyes on it, which the application process should achieve. And it's nice to have things buttoned up eventually.

I've spent like 9 months building https://github.com/VnUgE/noscrypt mostly around nip44, so I'm really hoping y'all can get us a spec that doesn't require another couple years of development for library devs :)

ChaCha20Poly1305 is a great choice on mobile due to lack of AES hardware acceleration. It’s also available natively in Apple’s CryptoKit as well as Google’s BoringSSL. I used it for Photon’s encrypted cloud backup for these reasons.

The first reply suggests first just using a Private Use range, and then later applying to IANA for a permanent number. Maybe wait with the IANA process until there's two implementations in beta stage and interoperable. The next steps, getting a Recommended=Y tick mark, is something you can do when people use it in production. But I'm not sure if that's worth doing. The author continues to point out how the secp256k1 curve is not ideal if you're designing a protocol from scratch. To be interoperable with other implementations we can just pick another curve from the list (e.g. the mandatory one). I would say that's for (far) in the future. I do think secp256k1 is a good choice for Nostr as long as Nostr itself builds on it. The curve also has the worlds largest bug bounty on it, making it a classic case of "bad in theory, good in practice". I don't think it's worth arguing with people about that though, as people did here: https://github.com/w3c/webcrypto/issues/82 - something about bringing a horse to water. cc @JeffG.