Thread

Replies (15)

↩ replying to Sebastix
> It is not recommended that users publish these encrypted private keys to nostr, as cracking a key may become easier when an attacker can amass many encrypted private keys.
GitHub
nips/49.md at master · nostr-protocol/nips
Nostr Implementation Possibilities. Contribute to nostr-protocol/nips development by creating an account on GitHub.
 In addition to this, ncrypt password should still have at least 128 bits of entropy, which typically translates to a password of 17 characters or more using a diverse character set. @npub1acg6...p35c
↩ replying to npub10000...vwqk
This is a wild theoretical concern with no practical attack. Nobody knows if, with a horde of encrypted keys, you could somehow hack them better than if you were just trying to go after one. If there is a good reason to put them online, that might easily overwhelm this kind of excessive safetyism. They should be very secure. Not only because of the good and excessive crypto (xchacha20, good cryptographers are now saying 8 rounds was enough, 20 is crazy) but also from the intense key derivation (scrypt, maximally memory hard) and further because the plaintext is both SHORT and virtually RANDOM.
The thing about passkey is the private key is meant to be un-extractable. It can be passed to keychain or google's alternative, but it can't be pulled out from either (or from the device enclave itself). That's seen as one of the biggest benefits of passkeys for a lot of applications. But for Nostr you can't really do that, even if you wanted to create an un-extractable nsec to mimic passkeys. One reason is the iOS device enclave doesn't support generating keys with the k curve.
↩ replying to npub10000...vwqk
Ah yeah, beyond the un-extractable private key thing and the wide support, there's nothing really special about passkeys. For cross-device stuff, IMO decentralised TEE cloud is the way to go, over FROST bunkers. Much much better UX. It's like nitro enclaves but decentralised. We use
dstack - Open Source Confidential Computing | Phala
Deploy secure applications with hardware-guaranteed privacy using TEE technology. Built for confidential AI, private cloud compute, and secure data...
 for some related things and it's good. The problem there is that many people here will get upset that it uses a blockchain that's not Bitcoin. Even though you need a blockchain to orchestrate the TEEs, and Bitcoin doesn't have the functionality, and nostr clients would only ever interact with the TEEs and not the chain, etc etc.
🛡️
↩ replying to fiatjaf
Aside from that (which in my understanding is basically a way to abuse Google and Apple syncing mechanisms, not really the "passkey" technology), yes, I agree with DHH and I think passkeys are a dystopic solution created by a cabal of evil corporations with the intention of locking up users and they don't actually solve anything as for most traditional apps they cannot ever replace passwords fully and they still rely on other authentication methods for recovery (i.e. an email address, preferably hosted at @gmail and tied to a phone number) so it's just making things worse in all fronts and I hope they die soon.
↩ replying to fiatjaf
Yes, I'm gonna use passkeys to help simplify nostr key management when accessing nostr apps. The nsecs will be importable/exportable. All the pieces are almost in place to put it online for everyone to test. I just need to go back to drinking coffee or someone to whip my back. Passkeys have become better with time. We don't need Apple/Google/MS/some-linux-distro-support anymore. E.g. Bitwarden (can be self-hosted) has a browser extension and native apps, supports passkeys and syncs keys across devices no matter the OS.
↩ replying to npub1l3cg...6vs2
That's interesting. We looked at the software-vault option for a related thing some time back (B2B use case, not Nostr keys) but the issue we hit is when any app requests the creation of a passkey on iOS, it's up to the user to decide where to store it, the app has no control over that, cannot force the user to a specific provider (I guess FIDO mandated). And pretty much every time user goes with hardware passkey and keychain. Is there now some way to influence that choice besides simply telling the user what to set up and choose beforehand?