What do you think about this model of nostr:npub1mu7nv2jkaq4xausnn098xc8tp3gzgf2w5r2cj68x8dnns0rktmysnsj5cl? https://github.com/breez/seedless-restore/blob/main/spec.md
I’m excited to work with Praveen of Cove Wallet on a new open standard for Bitcoin wallet cloud backup using Passkeys - no passwords, no key server trust.
Today wallets like BitKey provide a seedless UX with good redundancy but they require hardware. For spending wallets or users that want to start without hardware our proposal provides a compelling UX - Just do FaceID/TouchID to sync a Passkey to your password manager and done.
It’s an improvement over Photon since there is no key server to run for the wallet vendor and no PIN to remember for users (and no email/phone for PIN reset). The wallet just needs to regularly do a health check to verify the Passkey in your password manager can decrypt the cloud backup.
Let us know what you think. The goal is to develop this into an open standard that any mobile signer can adopt. Link below 👇
https://praveenperera.com/blog/passkey-prf-bitcoin-wallet-backup
Discussion
Breez’ spec is interesting if the user trusts his nostr relays to store the salt for prf. Without the salt the user loses his nsec. This is why I would propose to backup the salt along with the encrypted key material in iCloud/GDrive (see CSPP spec). This way the nostr user’s nsec could also be re-encrypted if the passkey needs to be rotated due to device compromise etc.
That's not how it works. The primary nostr salt is fixed. Then it can store additional salts.
Where is the primary salt stored?
The primary salt is an hard coded string defined in the protocol. Using it the list of the salts used by the same passkey can be obtained from the relays.
If by "the user trusts his nostr relays to store the salt", you mean to trust the relays to not delete them, trusting iCloud/GDrive is not better.
Also, Breez intent is to mitigate the trust by handling a relay dedicated to store the salts.
We’ve seen relays nuke their databases regularly which means users would ultimately rely on the breez relay to store their salt. As a user I personally prefer icloud to store my data longterm independent of a wallet vendor. But it is a matter of taste.
CSPP derives a master encryption key independent of the passkey to encrypt the nsec and stores the ciphertext besides the salt in icloud. Without it users would need to rotate their nsec when they rotate their passkey. I believe this is an important feature for the management of longterm user keys.
But PRF will be used in many different ways by different vendors. So I don’t expect convergence on one standard.
Oh and users get 2FA for free as an additional security layer when using iCloud/GDrive. Apple even makes users enable 2FA when storing passkeys https://support.apple.com/guide/iphone/use-passkeys-to-sign-in-to-websites-and-apps-iphf538ea8d0/ios
1. The client can regularly check the relays and republish the list of salts if they are deleted.
2. Every vendor can setup their own relay.
3. The list of salts is backup-ed automatically by ios/android because its in the app data and is not "secret".
4. The same list can be exported by the client to a simple text file if the user wants a wallet independent backup and doesn't want to run any app using this protocol for a long time.
5. Passkey rotation is generally not needed because the secret part of the passkey is not supposed to leave the TEE except when migrating from one vendor to another (using a secure protocol like CXP). In the exceptional case of a passkey compromise, the user can always move its funds to another wallet using a new passkey.
6. The UX cost of using iCloud/GDrive is very high (login, vendor auth)
Thanks for clarifying.
1-4: makes sense. The downside of relays is IP address (location) leakage to multiple untrusted server if users are not using a VPN.
5: I agree for a wallet use case. But for nostr the user loses his social graph.
6: the UX cost is zero for icloud-key-value-store (users are generally logged into their Apple ID on iOS). On Android there is a UX cost. The main upside I see is 2FA though. Compromise of a passkey is not unlikely on a desktop computer due to higher malware risk. Users could recover their wallet only on mobile devices. A user using yubikeys to secure their Apple/Google account would be resistent to an adversary that has compromised their laptop.
Re 5. The passkey is used explicitly for the wallet.
Re 6. A regular user doesn't store his passkeys in his desktop, and the passkey stays in his phone or physical key and only the prf result is sent to the desktop.
How does a user prevent sync of the passkey to his desktop? iCloud Keychain items are synced to all devices. Same with 1Password.
I like this proposal - it's simpler than ours and the stateless design is really elegant.
But it's not flexible enough for our use case. Two main concerns:
1. Doesn't support imported wallets
2. No good UX if passkey is deleted. User would have to create a new passkey/wallet, then decide how to transfer funds - consolidate all UTXOs in one transaction and lose privacy? Or transfer UTXO by UTXO and lose funds to fees?
nostr:npub1ey6qdmvzcgcsr883m9nspzz0mm037l26xtardzcskfsvc6gc7jssm9szvp nostr:npub1x8c26vdzu4v8my7ujljph2f73syql0kyd08ae0h4tk3gr22fdufqc38fl0
There are always trade-offs... There are a lot of different designs you can do with PRFs. We decided to prioritizie simplicity in our protocol, inline with *our* use cases. We don't need to support imported wallets or deal with UTXOs in our SDK. We've also vetted the approach with design partners.