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
provoost / Sjors Provoost
npub1s6…dwk4c
2024-08-27 17:35:50
Author Public Key
npub1s6z7hmmx2vud66f3utxd70qem8cwtggx0jgc7gh8pqwz2k8cltuqrdwk4cPublished at
2024-08-27 17:35:50Event JSON
{
"id": "460aba2af2493979ddd7efdd06cbde467c3cbe2b60f860e5c221bbd3a9a872bd",
"pubkey": "8685ebef665338dd6931e2ccdf3c19d9f0e5a1067c918f22e7081c2558f8faf8",
"created_at": 1724772950,
"kind": 1,
"tags": [
[
"t",
"mls"
]
],
"content": "Some thoughts *before* I read the draft NIP.\n\nI think we should propose an #MLS cipher suite that uses secp256k1 and reserve an identifier for it. That way we it can use libsecp256k1.\n\nThe 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.\n\nBy 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.\n\nMeanwhile 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.\n\nMLS supports switching ciphers for existing groups, so we can always add compatibility later. Or secp256k1-pill the other networks :-) \n\nFor the hash function sha256 makes the most sense.\n\nFor AEAD ChaCha20Poly1305 is used in BIP324 (encrypted p2p transport) as well as the Stratum v2 noise protocol.\n\nNot sure what to pick for the Key Encapsulation Mechanism (KEM), or maybe that's already covered by ChaCha20Poly1305?\n\nSo CipherSuite name MLS_256_???_CHACHA20POLY1305_SHA256_Secp256k1.\n\nhttps://www.rfc-editor.org/rfc/rfc9420.html#mls-cipher-suites ",
"sig": "f08a82485ddf4caf21bd354666be5fa79dd53bdcf1e61c7d5d23deadc83f4cd6f58c1bb13e5811b3b0353c55ee81452c73703a60b3fba149dc0affcea7498f19"
}