nosskey by ocknamo

GitHub

GitHub - ocknamo/nosskey-sdk: SDK for Passkey-Derived Nostr Identity a.k.a. Nosskey

SDK for Passkey-Derived Nostr Identity a.k.a. Nosskey - ocknamo/nosskey-sdk

The article you link says they are incompatible with open source but the passkey manager I use is open source and part of my password manager so how does that work then?

idk about benefits, but there sure are annoying bs design decisions.

they are corporate garbage

Beware of passkeys. They have UX benefits in the daily usage when compared to password+MFA but right now they are a platform traps. They build big garden walls.

I have an idea, but I’m not fully aware what the risks are of sharing ncrypt1’s in the open

> 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

It refers to the multi devices sync that currently is related to big tech cloud services.

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.

Thanks for the details. I meant to use Nostr just to do the cross-device stuff, I wasn't think how to generate and store the key in the first place. Maybe something like @fiatjaf's FROST bunker can help. But I'm not really sure that passkey's advantages are so strong that it is worthwhile. I should look into it further.

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.

Mine syncs to different devices to any PC I login I have my passkeys. Could self host the backend if I wanted to.

@arthurfranca has some ideas of how to use passkeys in a smooth cross-app syncing flow. I don't know all the details and I'm not 100% sure it works, but it may work pretty well for some users.

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.

Noted.

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.

Nice one. Are the Bitwarden passkeys bound to one site/app, or usable across them all? Are you using PRF derived keys like

GitHub

GitHub - ocknamo/nosskey-sdk: SDK for Passkey-Derived Nostr Identity a.k.a. Nosskey

SDK for Passkey-Derived Nostr Identity a.k.a. Nosskey - ocknamo/nosskey-sdk

?

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?

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.

> and I hope they die soon. Is that likely to happen? I mean, is there any indication that uptake is poor? Google abandons things if they don't catch on like they'd like, but I have zero sense for how successful (popular) passkeys are.