The crux of this argument is the following: The attacker must first create a compromised version of ECDSA. The attacker will now watch for consecutive signatures signed by the compromised ECDSA on the blockchain.

It's not as bad as it looks. Basically if your source code is audited and your random number is really random, you are fine.

A more easy to digest version of this news is here: http://www.coindesk.com/research-hackers-install-backdoor-bi...

So, the attacker must inject a malicious ECDSA signing code to the victims bitcoin client?

If I get this right, it doesn't sound like sensible research to me at all. If you are able to get code to the victims computer, then you can just steal the private keys right away.

Cold bitcoin wallets are supposed to be malware proof. If you have a piece of logic on a machine that never connects to the internet you have no way of stealing the private keys.

Similarly you can't just modify the message because the user can verify the destination address before committing it.

This is a method of sending out the private key within a normal looking message that no one else can detect (not even the person doing the offline transition).

> If I get this right, it doesn't sound like sensible research to me at all. If you are able to get code to the victims computer, then you can just steal the private keys right away.

The private keys are not on the computer, but on a piece of hardware (like the Trezor). The researchers claim that they can get the private key from the Trezor, by feeding it malicious, unsigned transactions. At least that's how I understand it.

I would like to see some analysis done on the Blockchain itself; it should be pretty easy to see if there are any compromised addresses like this according to their paper.

As it is, I think it's probably unreasonable for someone to worry if they're using a generally available audited ECDSA toolkit for their signature signing. You have to imagine that the ECDSA kit has a way of secretly storing these numbers and keeping track of their state across calls which might span months. Sounds hard to implement in an open source project.

On the other hand, the idea of something like a Trezor leaking information isn't too hard to believe; at least, now that this paper is written.

Those sorts of attacks don't seem likely to be economical, which is to say a highly secure hardware wallet implementation might be worth more as a company than any one user's single address. You probably couldn't do it more than once or twice before shit got real nasty.

You cannot distinguish malicious from legitimate signatures. From the paper: 'This can be done in such a way that only the attacker, who made the malicious implementation, can extract the secret from the signature, and that the distribution of malicious signatures is polynomially indistinguishable from legitimate signatures by anybody else.'

Hmm, I must have read too quickly. The initial analogy they used didn't have that property. Thanks!

Nothing really new here.