How is this better than “simply” having a “master” key pair (like Bip32 “xpub” and “xprv”) that generates disposable pubkeys for use in any client? (where the “xpub” is actually exposed for anyone to verify the “ownership” of generated pubkeys)
AFAF : nostr:npub16v82nr4xt62nlydtj0mtxr49r6enc5r0sl2f7cq2zwdw7q92j5gs8meqha
It's better because your identity remains in the main key. In any other scheme, your identity changes when you rotate keys, including BIP32 derived keys.
I see you've been fully Frosted. Welcome.
I like Frost, but I need it to work with encryptions.
You mean in the context of encryption decoupled from signing?
Ideally, decryption should not be decoupled from signing. I know FROST doesn't support it. But we need to figure out something that does support. That will be better than decoupling.
Sounds like a tall mathematical order. Maybe (big Maybe) something like Paillier threshold encryption running alongside Frost. But Paillier won't work for an nsec so you'd need a Paillier key pair as an "aux" keypair. And this Paillier setup would be encrypting an AES key on top of that, since using Paillier itself for encryption of long messages won't work. So then you'd be juggling Frost shards and Paillier shards, and in the case of the Paillier shards they'd be shards of an AES key.
Basically the user would need to request from the client another keypair if they wanted to start using NIP44 DMs.
With a good UX it could be abstracted away like how this nstart thing abstracts away all the Frost complexity. Like the whole thing can be behind a single "Do it" button.
Disclaimer: that all could be very wrong. My team looked into Pallier for some contest gamification stuff a while back, it's good for voting on contest entries and stuff, but getting blurry in the memory.
Goodness me, all solved with Frost2x already. Those guys are trolling-ly good.
Not if the “xpub” is made public … and added to events, and clients know to use it?
Requires a NIP for clients to “adopt”… but any other solution also would.
I’m too dumb to know the nuances here… but seems Bip32 is already authored and in use … ready to be adapted for Nostr use?
It will be impossible to get all clients to know how to use it. And if a few don't code it, we will never get enough adoption to completely switch into it.
The beauty of Frost is that all clients already support it. Because everything is solved in the key sharding/signing app. Everything else remains the same.
Yup, Frost is the most elegant backwards-compatible way.
First, that's circular logic. Saying we're not going to implement it because other people might not implement it is just silly.
Second, using a seed and xpub does not require all clients to change their code. In fact, you could do this today with standalone tools and absolutely no code changes (example below).
Third, using an xpub would provide all the features with **less complexity**, backward compatibility, and you get a seed phrase for your identity.
Example that you could do today: Using standalone tools, generate an identity keypair and then generate sub-keys for each client. Each client gets its own unique key. Put the xpub, path, and a link to the identity npub in the profile for each client. Those who support programatically verifying the link can do so and all other clients can verify the link in the same way they do now: post a note with each authorized key on the identity account.
Imposters can claim they're sub-accounts of someone else, but the xpub won't check out and there won't be any note on the identity account saying that's a legit sub-account.
While this doesn't require any code changes, obviously it would be a better UX to have the software verify the link, auto-follow sub-accounts, and so on.
You can also choose to have multiple personalities that are linked. Maybe you use one sub-account to talk politics, one to talk about your mad ping pong skills, and another to talk about gardening. There could even be an indicator in the profile to indicate that following this sub account should not follow all the others automatically. The possibilities are only limited by our imagination.
Also … wouldn’t sharded keys required user to have TWO clients to sign events? Maybe xpub solution is better cause it would not…?
nostr:npub16v82nr4xt62nlydtj0mtxr49r6enc5r0sl2f7cq2zwdw7q92j5gs8meqha , I may be calling on you for consult …
https://guggero.github.io/cryptography-toolkit/#!/hd-wallet
☝️ Fantastic tool. I used it a lot when I was writing tools to do these key derivations (just to confirm I fully understand the process). That'll let you do everything except use a xpub to generate more addresses.
A quick search turns up https://github.com/swan-bitcoin/xpub-tool to do that.
Use these tools to understand the concepts and then you'll be all set to implement it in your language of choice (or better yet, find a library that has already done so).
Corect me if I’m wrong … but NOW I see a few major differences in these two “key management” schemes :
FROST vs BIP32 …
1: “sub key” derivation via FROST (called “shares”) can be initialized (once or multiple times) from a users EXISTING npub, providing forward compatibility for existing pubkeys to act as “main identities”. BIP32 (afaikt) must generate a fresh xpub as the “main identity”, excluding existing npubs from reaping the benefits?
2: FROST handles a variety of “multisig” scenarios OOTB, allowing increased security if end users desire it. Implementing BIP32 alone would not provide multisig functionality?
3: FROST libraries are currently in development and ready to be implemented in Nostr clients. BIP32 is not?
OTHERWISE …
- both solve for “disposable” pubkeys which are cryptographically linked to a “main identity” pubkey.
- both require additional implementation by signers and native clients.
- both require a “connected” signer or native client to request the “main identity” pubkey from some remote service.
Forgive my ignorance as I wrap my head around this very real need. Have I missed anything?
nostr:npub1s9etjgzjglwlaxdhsveq0qksxyh6xpdpn8ajh69ruetrug957r3qpklxzl
Correct, but the "remote" might just be another app in the phone.
I think my conversion moment was seeing that Frost is more than “just” a multisig solution … it also handles the need for “disposable keys”.
IMHO, this is the greater need.
1. Correct
2. Correct
3. Correct on FROST (not sure about BIP32)
Frost and BIP32 are both “key management” schemes but I see them as serving different kinds of usecases.
BIP32 is good for the manual backing up, manual management, and manual transferability of a mostly “cold” private key.
Frost is good for the active use and management of a private key between a quorum.
I would not really want to use FROST shares for my private key cold storage nor would I want to use BIP32 for an active quorum.
Frostr’s benefits are:
- You can split existing nsec into t-of-n threshold of shares
- You can do this multiple times (still signing for the same npub)
- You can sign, encrypt, and decrypt with a quorum of shares
- You can recover nsec with quorum of shares
- You can rotate by creating a new keyset and orphaning old shares
- You can sign/encrypt/decrypt in a single round of communication
- Rounds of communication happen over nostr relays allowing client applications to effectively act as "remote signers"
nostr:npub1gg5uy8cpqx4u8wj9yvlpwm5ht757vudmrzn8y27lwunt5f2ytlusklulq3 I miss anything?
Thanks. I have a couple more Qs I can’t seem to find answers for … coming from a client dev :
1: does a “share signing” client have access to the “main” npub? This seems important in many ways, but I’m not clear on this in what I’ve seen of your ‘bifrost’ codebase.
2: if so … NIP07 only specifies that signers implement ‘getPublicKey()’ … which pubkey does ‘frost2x’ output ?
3: what happens with events signed by an orphaned share?
I’m sorry for being a bit dense … I guess I’m simply unclear if the ‘pubkey’ field of signed event contains the ‘main pubkey’ or the share string?
window.nostr.getPublicKey() outputs your npub. Frostr doesn't change that.
Frostr works with your existing nsec and outputs your existing npub.
Frostr allows you to put your nsec into cold storage, and use it to generate new sets of shares offline. It doesn't change your nsec/npub.
Frostr simply splits your nsec into many shares, so that one device does not hold your entire npub, only a part of it.
BIP32 works with frostr (technically not yet, have to fix a bug first), so you can derive child keys from your nsec, and frostr can sign with those child keys.
BIP32 is not utilized by nostr AFAIK, so child npubs will not be recognized as an extension of your main npub. However if nostr protocol decides to implement BIP32 (or any key derivation scheme really), then frostr will work with it.
Using your nsec with frostr also does not lock you into using frostr. It doesn't do anything strange or proprietary to the final signature, so your bare nsec/pub will validate signatures made with frostr.
From a cryptography perspective, you cannot tell the difference between a signature from frostr, or from your bare nsec. They are the same signature.
I hope this helps.
This helps a lot!
As Ive mentioned earlier … my primary concern for Nostr scalability is that users get to have “disposable” keys. While Frostr is not “billed” as solving for this need, I’m coming to see that it will (with an appropriate UX). I hope I’m right on this… as I push fwd integrating Frost into my onboarding client this year …
Also, orphaned shares can't sign for anything. In fact, no single share can sign for anything. They can only contribute a part of the signature. You need a qurom of shares to participate in order to create a full signature. If you orphan a compromised share by deleting your other shares, then that orphan share is worthless.
