Oddbean

How about you have me on your bitcoin review show and we chat about it in detail so we can get into all the technical details and how realistic various attacks are :). nostr:note1ftmvf7qlfnpvfjv5cd80980qds4xzvemqyd2kcldcf5tfnlmsxnsy6k6qd

That sounds like a useful episode. IIRC rfc6979 doesn't apply to Schnorr, so if you use it and don't support Taproot you're good for now? I also forgot if you can verify it, or that it's only a useful tool for wallet developers to avoid a footgun. https://datatracker.ietf.org/doc/html/rfc6979

If you sign on two devices and check that they match, yes, that addresses the issue, but now you have two devices with your seed and a very annoying UX (that might also fail due to fine signature grinding differences). Really HWWs need to implement anti-exfil and generate keys with computer randomness - there’s no excuse for the fact that hardware wallets are trusted, they don’t need to be!

Having the same seed on two devices wasn't what I had in mind. In that case it's better to use MuSig2 (regular multisig has the same problem, though both devices would need to be compromised). Why would adding computer randomness at seed generation time help with exfill at signing time? If there an RFC / BIP for anti-exfill at signing time?

The issue with exfil is that the computer can’t detect whether the nonce is malicious or not, so it can’t block the attack. What you really want is for the nonce used to sign to be provably random, by simply having the computer add some of its own randomness to nonce, plus some deterministic message+pk hash from the hardware wallet (ala 6979). That way the HWW cannot exfil. While you’re at it you should also include randomness from the computer in the seed generation process so that the private keys themselves don’t rely on only the HWW. Neither of these are complicated, FROST is built around the same kind of nonce agreement protocol and including the randomness from the computer in key gen is just a matter of adding a second private key.

Yea, someone probably should. Probably one of the hardware wallet vendors who are complaining that there’s no standard and that’s why they never bothered to implement it (nevermind that it’s implemented in secp256k1-zkp and can be done at the HWI driver layer, but indeed it’s be better as a PSBT field).