nostr:nprofile1qqspwwwexlwgcrrnwz4zwkze8rq3ncjug8mvgsd96dxx6wzs8ccndmcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qtxwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tmwwp6kyvt6w46kz6nyxa6nxumc8pu82wfj09shvwt2wau8qu3cxvukxuesdd3nxufkws6nvanyx46njufsxvehsmtgwd4nvcejw43n7cnjdaskgcmpwd6r6arjw4jszxrhwden5te0dehhxarj9enx6apwwa5h5tnzd9az77vr4lw already engaged with the MLS team to get our curve included/referenced.
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
Discussion
Ah, found the thread: https://mailarchive.ietf.org/arch/msg/mls/iIh-1MLGsVhWNeGPOU5Y77ZkeTI/
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 nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc.
💯 Yeah. Sounds like we're on the same page. Spec improvements, then demo using the default ciphersuite, then custom secp256k1. 🤝
