Topic: bad signatures, java RandomSecure, malicious (Read 800 times)

Correct.

How would sending Bitcoins to an address compromise it? You would be signing for your own accounts so you could only compromise accounts you fully controlled.

It doesn't work that way. There's nothing I can do to reveal your private key without physically stealing your wallet unless you happened to sign two messages or transactions with the same random number. I could have a "random" number generator that always returns the same number (like Sony's implementation of ECDSA signatures) and it wouldn't affect your keys at all, but any time I signed more than one transaction from the same address I would compromise one of my own private keys.. which would be my only private key if I were using the Sony non-random number generator.


I'd suggest reading up a little on Elliptic Curve cryptography in general (and ECDSA in particular), even Wikipedia gives a really good explanation of how it works, but if math isn't your thing then maybe not. Basically there are two issues.

The first is "weak keys". If I'm using a weak random number generator, there's a chance I could generate a key that's much easier to reverse from an EC point (public key) back to the large integer it's based on (private key). In that case, my key will probably be compromised. Unless you're also using a weak random number generator, your key is not affected, only mine.

The second is signatures. An ECDSA signature requires a random nonce (number used once), that number is not your private key, it's a new random number generated for every signature. As the name implies, that number is never supposed to be used more than once with the same key. If I'm using a weak random number generator and signing multiple transactions or messages with the same key, there's a good chance I'll end up using the same nonce with that key more than once. If that happens, it's trivial for anyone who understands ECDSA and sees those two signatures to "recover" my private key. Once again, my key is compromised, but unless you're also using a weak random number generator your key still isn't affected.

I'm sure the second issue is much more likely and more common than the first, but neither of them can compromise your private keys unless you happen to be using the weak random number generator. Even if I generated a thousand signatures with my Sony non-random number generator there's still nothing (short of stealing your wallet.dat) that I could do to reveal or compromise your private keys. Realistically, I can't even know your public keys until you publish them on the blockchain as part of a transaction since your address is actually a RIPEMD160 hash of a SHA256 hash of your public key.

Basically I can sum it up with these 3 things (the tl/dr):
1) Don't use random number generators that are known to be weak. This issue with Android has been known for quite some time, games that rely on random numbers have always acted strange on that OS.
2) Don't reuse Bitcoin addresses, if you never sign more than one thing with any given private key then the second issue can't affect you even with a weak random number generator.
3) A weak random number generator only affects your keys if you're the one using the weak random number gnerator to generate keys and/or signatures.

So everyone is updating their android clients to use the dev/urandom method so that transactions signed are not able to reveal the private keys of both addresses involved.

That is my understanding of the issue.


But what is to prevent someone from simply generating an address using RandomSecure and sending bitcoins to other addresses simply to compromise them?

In my understanding of this scenario, this is a major MAJOR security hole

the only way to avoid this would be to update valid address generation in the bitcoin protocol in a way that SecureRandom cannot generate a valid address at all.