Oddbean new post about | logout
 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. 
 Sounds like someone should write a BIP (including the extra psbt fields needed), for the signing time anti-exfill. 
 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). 
 Sadly no implementation exists for Taproot AFAIK, but the BitBox folks have a PR to secp256k1-zkp at least.