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).
Look like nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 is avoiding opinions he disagrees with on his podcast, so which one should I go on instead to talk about hardware wallet issues? 
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.
I understand the data to be signed and tied to an Apple ID. It may well also be tied to some per-device factory-sealed key. I mean you can always buy 256 real AirTags but hardware modifications are much more likely to be detected than software ones.
My point was I’m not sure you can pretend you’re *any* devices without being an Apple device. In any case nostr:nevent1qqsqac7czr2hk05gkf0l5s59tg3tz8xyspn9ea7aqxrvg9pswev8y8spzfmhxue69uhk7enxvd5xz6tw9ec82cspz3mhxue69uhkummnw3ezummcw3ezuer9wcq3gamnwvaz7tmjv4kxz7fwv3sk6atn9e5k7qglwaehxw309ahx7um5wgkhyetvv9ujucnfw33k76tw9ehxjmn2vy728fpa
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!
You can definitely include a GSM chip for cheap, but now the device board actually looks visually different, which people can identify, even if admittedly relatively few would. Still, if you did this en-masse it’d likely be discovered before too long, whereas a malicious firmware likely would not.
It’s also implemented in secp256k1-zkp.
Can someone please link me to an actual specification for anti-exfil
cc nostr:npub185h9z5yxn8uc7retm0n6gkm88358lejzparxms5kmy9epr236k2qcswrdp
Any method of cooperatively building a nonce (eg stuff things do for FROST, it’s the same problem).
In theory, but I’m not sure if you can transmit arbitrary messages over that without being Apple.
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
Should we take Bitcoin Core seriously?
To nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8's credit there is no established standard for PSBTs with anti-klepto and people go on about recommending TAILS instead of hardware wallets missing one of my favorite aspects of hardware wallets: Not only are hardware wallets designed to protect the user from a compromised companion app but the companion app also can verify what the hardware wallet is doing.
Just as with multi vendor multi signature you can remove single points of failure, multi vendor between companion app and hardware wallet can remove single points of failure. With TAILS, that TAILS boot device and the PC it runs on are single points of failure.
Bitcoin Core should support anti-klepto between an online networking instance and an offline signing instance. The TAILS with Sparrow stack is way too complex to safely say it won't use biased nonces else but if it has to use anti-klepto, there is no room for leaking keys.
AFAIU you can implement it entirely in the driver rather than in the wallet itself (BitBox apparently did this for their HWI driver).
Except you aren’t…it’s very (cryptographically) easy to build a hardware wallet which cannot steal your coins*! But no one does, that’s absurd!
* without cooperating with your computer/phone.
No? Sparrow supports anti-exfil with BitBox Afaiu.
You can just download those software packages once and rarely upgrade and you’re safe. Unlike a compromised HWW which can lie to you about the status of its firmware.
Multisig is, passphrase is not.
That’s not a scalable attack. In that model the attacker has to be kinda nearby when you use the HWW.
Oops, sorry, I forgot we can fix both sides of malicious hardware wallets - a malicious hardware wallet should not be able to steal your coin, it’s not complicated to force attackers to compromise both your computer *and* hardware wallet, but current devices just…. Don’t. That’s embarrassing!
(Except for multisig setups). nostr:note1m80q3p6pfxl6elt7dcpu076fmcwjymz942z4esumm5ku3mrsz2lqanga9y
A Laptop is not a device purpose-built to store millions of dollars in bearer-assets. It’s a much less juicy target.
