How about 24 words? Nsec is 32byte which, for a 2048 word dictionary, requires 24 words. :(
Discussion
6 lines of 4 words each is borderline doable in terms of manual typing
that long ass number ? i'm not typing that out - forget it.
Just like Bitcoin, you should generate the private key (the 32 bytes), from the words, not the words from the private key. Bip-39 feeds the words as a string into a PBKDF2 using SHA-512, which provides the master seed for HD wallets (64 bytes). So whether it's 12, 17, 24, or 102 words, it will all work, however any more words then 12 doesn't add any extra security.
Btw, why not implement a Bip-32 like hit hierarchical deterministic nostr accounts? This way you could have the master account that can access it's subordinate accounts.
We can implement. But we don't have the seeds for any of the keys people are already using today. And no one will want to migrate to a new key and lose everything just because of seed words. We have to find a way to make it work with the current keys.
That's "easy". For non seed keys, use a different type, and encrypt the non-seed key under the seed key (and store it). You could do that for seed keys as well to have only a single type.
Sure, but then we will def need more than 12 words.
Why? I'm not exactly sure what Custom Designed meant but it sounded to me like you could store old keys encrypted with the new keys. So when migrating to HD mnemonic based key backup, you use a certain key derivation for a symmetric key and then store your old key(s) in a special event but encrypted with the new key. So when you restore from the mnemonic, the client could ask you which of your accounts to use. It could show you mentions of your legacy account even after switching to a new pubkey etc. The client could sign notifications that the legacy key was rolled over to the new key (whichever sub-key currently is active).
If you encrypt the old key with the new key you would have to store the key + an encrypted payload. There is no way to create recreate a seed from one the keys it could generate. And because of that, you have to save both the words and the encrypted payload which given that the private key is already 32 bytes, requires more than 24 words for the two things (payload + seed) combined.
I meant you store the legacy key(s) in a nostr event. After all we trust our crypto. This event of course would be fatal if it went lost but as this could be a special kind, it might get special care on relays.
Get a new 12 words mnemonic M. Generate the master seed. Use m/12'/12' as encryption key for your kind-1212 event where legacy keys get stored.
Ohhh saving nsecs on Nostr feels dangerous.
What the other guy said. The standard should not encode the current keys with mnemonics. 12 words is plenty secure. At least until people start losing their Bitcoins secured by 12 words nostr should not bother using 24 words.