Bitcoin Forum
April 26, 2024, 05:03:04 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: bad signatures, java RandomSecure, malicious  (Read 776 times)
stslimited (OP)
Hero Member
*****
Offline Offline

Activity: 546
Merit: 500


View Profile
August 14, 2013, 05:25:04 AM
 #1

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.
1714107784
Hero Member
*
Offline Offline

Posts: 1714107784

View Profile Personal Message (Offline)

Ignore
1714107784
Reply with quote  #2

1714107784
Report to moderator
TalkImg was created especially for hosting images on bitcointalk.org: try it next time you want to post an image
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
stevenh512
Full Member
***
Offline Offline

Activity: 137
Merit: 100



View Profile
August 14, 2013, 09:50:19 AM
 #2

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.

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. Smiley

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

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.

This signature intentionally left blank.
JoelKatz
Legendary
*
Offline Offline

Activity: 1596
Merit: 1012


Democracy is vulnerable to a 51% attack.


View Profile WWW
August 14, 2013, 09:53:28 AM
 #3

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.
Correct.

Quote
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.
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.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!