Oddbean

Are we not using Schnorr sigs? That should allow multi signature schemes where only collaborating machines can sign a message. Federated custody of social media keys. I could imagine endorsing such an nsecbunker using 3of3 sigs.

Is it possible to take an nsec you already have and split it into 3 somehow, give one shard to each server and then they somehow collaborate to make a signature? I think you can't do MuSig2 for that, but maybe some other, simpler (less safe?) algorithm? I've asked @waxwing this once but he never answered.

Ah that code is old, I should take that repo down. The actual code is available here: https://github.com/m1sterc001guy/roastr ROASTr is a module for fedimint that enables collaborative signing of nostr notes. It uses roast, which is just a wrapper around frost.

Pretty sure I agree that FROST is closer to the mark in what @fiatjaf is looking for, but specifically the signing algorithm and not the keygen algorithm. FROST (and Pedersen DKG before it) were advancing the state of the art by allowing for no central party (or aggregator/dealer) to be in possession of the whole private key at any time, either in key generation, or in signing. Here I guess you want to reset back to the earlier SSS basic idea of having the central party know the key in advance, then construct the individual shares such that they sum to the pre-existing key x, instead of following FROST's KeyGen to generate the shares. But the "massive caveats" I mentioned in the other post still apply; it seems unlikely you'd want to allow the possibility to collude to take your full key.

No, I don't want to reconstruct the key, I just want these providers to construct signatures, which apparently FROST can do safely -- I don't get why you can't do that with MuSig2 (wait, I guess it just doesn't work because MuSig2 has the "distributed key generation" step built in). So I, as a user, don't have to do any cryptography or hold any keys during my daily life as a Nostr user, I can just instruct clients to fetch signatures from a server somewhere, and that server will coordinate with the 3 entities that hold my key shards to get a signature, then return the signature to the clients and, boom, I have a signed event.

Re : "No, I don't want to reconstruct the key", I don't really understand; I didn't use the word 'reconstruct' in that. "I just want these providers to construct sigs safely which apparently FROST can do". But the point that's at issue here is you want them to do that with *your* key. FROST and MuSig both allow multiple parties to collaborate to create signatures safely, with the main difference being that the former allows it for t of n and not only n of n. *Neither* provide for the key to come from some central party. As for distributed key gen, yes they both do it, they have to; but they do it in radically different mathematical ways (because of the t of n requirement for a start). And retrofitting them to allow you to start with a key "x" and then split it up and give it to them probably can work, but my caveat point is, if you care that they can collude to take the whole key, between them, then that's not great.** In FROST's case, it happens to be polynomial evaluations that you share, but it's still designed so that t of those shares (in a t of n scheme) are enough to reconstruct your signing key. **In any such collaborative signing scheme, by definition, the key can be reconstructed by the authorised threshold t, because they can share their nonce contributions and extract the private key using the nonce. This isn't usually discussed, but here we have an external party that'd prefer not to be attacked by the group, so to speak.

I remember thinking "I don't know if that's possible" but also thinking "does that question make sense"? If i use some xor/whatever to make 3 shards, don't I still have the original secret key. If that doesn't matter, and you just want the others to attest, or something, then just use their own keys? I guess I just don't get your point. Obviously both N of N and M of N collaborative control of newly generated keys is well understood (albeit a bit complicated!).

The point is that I have my own secret key that I generated, but it's annoying and unsafe to paste it in Nostr apps everywhere -- and we want people to use multiple apps for multiple tasks, all with the same identity. So the solution is to have the NIP-46 bunker thing that keeps listening for requests to sign coming from authorized apps. But I don't want to run such a bunker daemon, I have no idea of how to do it, it's annoying blablabla; therefore I want to delegate that task to some third-party to run this daemon for me. But I don't want to give this third-party my key, it would be much better if I could split my key in 3 once, give 1 shard to a different provider and trust that they won't collude to recreate my key -- but then they cooperate to sign stuff on my behalf and is as if it was me who signed it.

OK yes I see. It seems difficult because a musig aggregated key is not a linear sum, to avoid the possibility that less than N can forge a full signature using key subtraction attacks. Constructing the key is an interactive process that produces an unpredictable final key, by design. Perhaps you can attach a proof of knowledge of each "key portion" works though: you distribute secret keys x1, x2 and x3 such that x1 + x2 + x3 =x, your key. Then when they go through the signing process they add a signature over their key portion at the start. This prevents them from doing key subtraction to forge with < N parties. Then they can go through the normal process of 3 round MuSig - commit to their R portion, then reveal their R, then the final signature on P is the sum of the signatures on P1, P2, P3. Two obvious problems stand out: they can collude to extract your full key; usually that is not acceptable. And of course the fact that signing becomes interactive. Overall it doesn't seem very practical, and heck, don't even quote me that it's possible or sound, I'm not sure. Even with the massive caveats above. Various kinds of delegation or setup with the initial key, whether using existing FROST or MuSig, feel like they make for a sounder approach.

I think we could make it so the possibility of these entities colluding is small and then tradeoff is reasonable for most people (but not for all, of course) -- the alternative of trusting a single provider to hold absolute power over your entire identity, like x.com, is far worse. I don't get what you mean by "various kinds of delegation or setup with the initial key". What do you have in mind there?

About initial setup/delegation, my thinking is: a protocol could allow you to delegate authority to do specific things (like sign) by a direct signature on your main key saying "this sub-key is authorised to sign these events" and then that subkey could be generated collaboratively in a normal way. Common way of using digital signatures (delegation to another key), but admittedly it can be a can of worms...

A bunch of proposals for variants of doing that stuff have been (and continnue to be) suggested. I don't know what is the best way (they all look flawed to me given that there is no single source of truth for what is the latest update on the subkeys of each person) -- but even with all that decided and solved I think it's a bad idea because it would add so much complexity to clients and/or relays that Nostr would essentially cease to work or instantly centralize around a single big entity that would become the central source of all truth and the almighty index of all events. That's why I'm considering these other ways.

Subkeys will be time boxed like X.509 certificates or GPG subkeys have done for centuries. Nostr won't stop existing but if this upgrade flushes some of the nincompoop devs out of the community that can't handle something this simple then that's a win-win.

@jimmysong's reply below is correct, FROST with trusted dealer would solve your use-case here. Of course @waxwing's point is also valid: If you want true multisig security you'd need to be certain that you securely erase the distributed shares on your machine afterwards, and of course erase the original secret key (except for maybe keeping a paper backup). Still, it's a valid approach if you are OK with those assumptions. I'm currently working on a BIP340 compatibility pull request into the ZCashFoundation's FROST implementation (Rust), I believe it should work to produce valid Nostr sigs. https://github.com/ZcashFoundation/frost/pull/730 If you use a python stack, check out @jesseposner's FROST implementation here https://github.com/jesseposner/FROST-BIP340 @AVERAGE_GARY linked to my FROST BYOK article but that would only be practical if you wanted to create a joint key from existing (static) npubs. I don't think it's useful for splitting an existing key.