Nostr Web Client

But my question here was more if it's a possible and if it's a good idea to take someone's existing private key and split it in two, store each shard in a different device so they're never united again, then use some protocol to produce signatures without having to bring them together.

waxwing 1y ago

As opposed to just making a fresh 2 keys? I mean it'd always be easier to just do that ofc (and authorise new key(s) with old).

Hmm with MuSig2 it's not possible I think. The aggregated pubkey is designed to withstand key subtraction attacks, and that means you can't backsolve to make the aggregated pubkey be equal to the preexisting pubkey.

So you're in a weird area ... try do just combine signatures naively without the protections of musig2 against adversarial behaviour? Very unlikely to make sense since you're doing this for improved security in the first place.

Reply to this note

Please Login to reply.

Discussion

fiatjaf 1y ago

> As opposed to just making a fresh 2 keys?

Yes.

> try do just combine signatures naively without the protections of musig2 against adversarial behaviour?

I see, that makes sense.

> Very unlikely to make sense

I think the use case is something like:

1. I have been using this raw private key in my desktop and so far it hasn't leaked, but I am afraid it will eventually leak.

2. So I split it in 2 and put one shard in a hardware wallet and the other I leave on the desktop, delete the raw key.

3. Now to sign events I need the combination of the two devices, communicating somehow to produce a signature.

(As I write this I realize it's not a very good use case, so maybe this discussion is a waste of time.)

What could go wrong? If one of the two shards is leaked to an attacker, could him find out about the other shard somehow?

Or, a more generic question: since the two shards are pre-defined by myself, are they immune to the key subtraction attack since that would require the attacker to use an entirely new key?

fiatjaf 1y ago

This may or may not be related: https://crypto.stackexchange.com/a/103298/54810

waxwing 1y ago

Yes it is, good find, tim ruffing covers it well in that answer. And my bad for not remembering it. If you look at e.g. FROST they argue strongly that for the even more tricky case of *threshold* signatures (ie M of N, not just N of N, which as you can imagine is much more delicate), that a proof of knowledge of key shares is realistically essential, I came to the same conclusion looking at the security proofs of these things - it's stupidly complicated otherwise. MuSig2 is a very "industrial" protocol, by which I mean, partly because of the requirements of bitcoin, they push the limits on sophistication in order to achieve the most performant and smallest interactivity footprint possible version of multisignature. The cruder way is "key + proof of knowledge of key" in setup and then "nonce point + proof of knowledge of nonce point" in signing. But while that is kind of "the" solution to this niche problem, I'm for sure not going to recommend doing some half cocked protocol instead of doing the sane thing of creating fresh keys and then following the very well analyzed standard(s).

On your "more generic question", sure, the immediate thought is "well this was my secret key in the first case so it can't be adversarially chosen", yes, but the signing process has another "key", namely the nonce "shares" you do for each signing event. If they are adversarially chosen you again can get a forgery; in fact you can *use* this to extract the private key of the other signer. This is why the original MuSig was patched up to commit to the nonce points first, in an extra round.

If you add that 3rd round in, the overall idea is *perhaps* safe ... indeed that 3 round musig is quite nice, when I coded it for pathcoin I used that instead of MuSig2, it's a simpler security model at the cost of 3 instead of 2 rounds of comms. But meh, this is too slapdash, i suspect.