--- Log opened Sat Feb 25 00:00:54 2023
06:13 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
08:49 -!- kcalvinalvin [~kcalvinal@ec2-3-38-183-204.ap-northeast-2.compute.amazonaws.com] has quit [Quit: ZNC 1.7.4 - https://znc.in]
08:49 -!- kcalvinalvin [~kcalvinal@ec2-3-38-183-204.ap-northeast-2.compute.amazonaws.com] has joined #secp256k1
10:00 < BlueMatt[m]> If you need to build frost partial nonces for an offline device, can those nonces be built with bip32 non-hardened derivation even if the keys doing the signing are as well? If you squint it looks like a nonce reuse issue (cause the other multisig parties know the offset between nones), but others are claiming it works.
10:03 < andytoshi> definitely not, if other parties know the offset between nonces that's nonce reuse
10:05 < sipa> Yeah, known linear (or low degree polynomial) relations between nonces is just as bad as reuse in general (whether schnorr/ecdsa/musig/frost).
10:09 < sipa> This precludes any mechanism that permits other parties to predict your (public) nonce, in fact.
10:10 < sipa> So anything based on deriving nonces from an xpub or so won't work. Hardened derivation is ok, but of course still requires sharing the actual public nonces for every new signature.
10:27 < BlueMatt[m]> right, that was my guess
10:37 < BlueMatt[m]> even though each nonce is only used with a different signing key
11:00 < andytoshi> oh, if it's used with a different signing key every time, and nobody knows the relationship between the _keys_, i think you are technically ok
11:01 < andytoshi> but IMO you are playing with fire
13:58 < BlueMatt[m]> No you know the relationship between the keys and the nonce lol
13:58 < BlueMatt[m]> Cause both bip32 publicly derived
13:59 < sipa> @andytoshi Hmm I guess if you had actually unrelated private keys, and only signed strictly once with every key, you could have a single hardcoded nonce you use for everything?
14:05 < sipa> That goes against my intuition, but as long as it remains n signatures (= equations) and n+1 secrets (n keys + 1 nonce), I guess it's fine?
14:18 < andytoshi> yep
14:18 < andytoshi> BlueMatt[m]: ah, then no, you're still screwed :)
14:19 < andytoshi> my intuition is that security-wise, there's not really any difference between keys and nonces ... except that keys are assumed to be fixed
14:36 < sipa> Right, and you can't have both be predictable.
--- Log closed Sun Feb 26 00:00:55 2023