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.
What do you think about this model of nostr:npub1mu7nv2jkaq4xausnn098xc8tp3gzgf2w5r2cj68x8dnns0rktmysnsj5cl? https://github.com/breez/seedless-restore/blob/main/spec.md
Discussion
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.