notedeck: using private key impl from nostr

5 views
Skip to first unread message

kernelkind

unread,
May 5, 2024, 4:35:38 PM5/5/24
to d...@damus.io
It makes sense to stick with pubkey in enostr. The usage of public keys is extremely prevalent in the codebase and it's important for it to be as performant as possible, but the private key is used much less often, and carries much more significance if there is a bug or mistreatment of the key for obvious reasons. For that reason, I think we should use an external library which already implements many security features and is used in other projects already.

I understand we're currently using nostr-sdk as a temporary solution, but I think we should remove it and use nostr instead (https://crates.io/crates/nostr/0.30.0) as a more permanent solution. It is a subset of nostr-sdk and has much fewer dependencies. And then we could also use the nip49 EncryptedSecretKey from nostr as well for storing the key to disk. 

I understand wanting to have as few dependencies as possible, but I think it could be worth having the nostr dependency for something as significant as the private key.

William Casarin

unread,
May 6, 2024, 1:02:14 PM5/6/24
to kernelkind, d...@damus.io
Yes for the private key we will likely need all of the associated
operations for signing + the nip49 thing for desktop. It looks like it
has nip44 support as well which we will need.

We can just keep a raw byte serialized version in our keychain for
operations that need frame performance like equality matching, etc.

It's clear there will be many key representations:

- XOnlyPublicKey
- PubkeyBuf([u8; 32])
- Pubkey(&'a [u8; 32])
- SecretKey
- etc

as long as we don't do silly things like convert XOnlyPublicKey -> [u8; 32]
within per-frame within our UI code we should be fine.
Reply all
Reply to author
Forward
0 new messages