Anti-exfil protocol can't be verified on multiple hardware wallets

Question

Regarding the nonce side channel attacks detailed in posts like this one by Blockstream. Which references this mailing list by Pieter Wuille. The idea is to add another layer of protection against a malicious hardware wallet by requiring it to prove that it incorporates some randomness provided by the software wallet that is used to broadcast the signed transaction.

Comparing the anti-exfil protocol to deterministic nonce, Pieter says:

In case HW uses a deterministic algorithm, it is possible to protect against the MHW case by spot checking HW's behavior, by using an externally known secret/seed. However, we'd like to have better than just spot checking security, and for protection against side-channel attacks we may want something that keeps working even when randomness is used by HW.

But this is precisely what I like about the deterministic nonce. I can buy as many hardware wallets as I want to verify that they all produce the same signature. And even test it against some airgapped software wallets like Electrum. I can even write my own simplistic RFC6979-compliant wallet with python to verify the signature is the same.

1. With deterministic nonce, there is no limit to the number of hardware and software wallets with which I can sign the same transaction to verify that the signature is the same. With anti-exfil, I am limited to only the single HW and the single SW used to broadcast the transaction and must hope that at least one is not compromised.
2. The whole idea of hardware wallets is that we think of them as more secure than the software wallet/hot machine. So surely 2 hardware wallets (used to verify deterministic signature matches) is more secure than one hardware and one software wallet as mentioned in point #1?

Answer 1

Your analysis is correct, in that "verified" deterministic signatures obviate the need for a protocol like anti-exfil. However, the trade off that anti-exfil makes is that it does not require signing with multiple devices before knowing that the signature does not leak data.

Consider that without anti-exfil, you must sign and check every input with multiple devices before exposing the tx to the network. It is not enough to perform this validation after the fact; by the time you determine that different signatures have been produced, enough bits of your private key may have been leaked to allow theft either directly or by grinding the remaining bits.

Not using anti-exfil means that to achieve the same level of leakage assurance, you must sign every tx with multiple devices and verify the signatures before sending. That's probably fine for an offline vault or cold storage, but it is neither practical nor supported by warm/hot wallets for typical send flows.

Anti-exfil exists to provide assurance for the common case of a single signing device. If you are prepared to sign and compare with multiple devices then you likely don't need to use it. Like everything in cryptography there is a trade off between convenience and security; it is up to the individual to determine where on that spectrum they feel comfortable.