Our great sponsors
-
-
ecdsa-private-key-recovery
A simple library to recover the private key of ECDSA and DSA signatures sharing the same nonce k and therefore having identical signature parameter r
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
> Interestingly, there was a lot of speculation and misinformation. So even on Hacker News, this topic is still only vaguely understood.
This is not a new revelation, and a similar vulnerability is discussed in Mastering Bitcoin: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06...
> The way I understand it, it makes it completely impossible to use Bitcoin in a trustless way. Even with an air gapped hardware wallet, you are always at the mercy of the wallet manufacturer and the delivery chain that gets the wallet to you. If it gets swapped out on the way to you, you are at the mercy of whoever swapped it out.
Bitcoin's threat model assumes assumes your client software follows specifications. Airgapped hardware wallets aren't designed to eliminate "Reflections on Trusting Trust". Assuming your scenario, the attack can be tested in a similar way to that outlined in "Fully Countering Trusting Trust through Diverse Double-Compiling" (https://dwheeler.com/trusting-trust/).
> Show me an actually malicious hardware wallet that becaves as you've described, and you'll have made your point.
I'm not the OP and although I agree with you, you may be interested in the corollary for a "stronger" attack than OP defined:
https://bitcointalk.org/index.php?topic=581411.0 and https://github.com/tintinweb/ecdsa-private-key-recovery
Constructing such an airgapped hardware wallet is as trivial as a raspberry pi running a patched bitcoin client. In my opinion the more realistic construction than a that of "Reflections in Trusting Trust".