Bitcoin Forum
September 19, 2018, 12:28:12 AM *
News: ♦♦ Bitcoin Core users must update to 0.16.3 [Torrent]. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 [6] 7 »  All
  Print  
Author Topic: Bad signatures leading to 55.82152538 BTC theft (so far)  (Read 58206 times)
TiagoTiago
Hero Member
*****
Offline Offline

Activity: 616
Merit: 500


Firstbits.com/1fg4i :)


View Profile
August 14, 2013, 11:09:20 PM
 #101

And wouldn't that expose data encrypted by other apps to similar security issues?
No. The issue has nothing to do with exposing encrypted data but with signatures exposing private keys.
Encryption isn't weakened when the random number generator is bad like this?

(I dont always get new reply notifications, pls send a pm when you think it has happened)

Wanna gimme some BTC/BCH for any or no reason? 1FmvtS66LFh6ycrXDwKRQTexGJw4UWiqDX Smiley

The more you believe in Bitcoin, and the more you show you do to other people, the faster the real value will soar!

Do you like mmmBananas?!
1537316892
Hero Member
*
Offline Offline

Posts: 1537316892

View Profile Personal Message (Offline)

Ignore
1537316892
Reply with quote  #2

1537316892
Report to moderator
Einax Airdrops and Bounties made easy! List your ERC-20 token
FREE
ETH markets launching soon!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1537316892
Hero Member
*
Offline Offline

Posts: 1537316892

View Profile Personal Message (Offline)

Ignore
1537316892
Reply with quote  #2

1537316892
Report to moderator
1537316892
Hero Member
*
Offline Offline

Posts: 1537316892

View Profile Personal Message (Offline)

Ignore
1537316892
Reply with quote  #2

1537316892
Report to moderator
1537316892
Hero Member
*
Offline Offline

Posts: 1537316892

View Profile Personal Message (Offline)

Ignore
1537316892
Reply with quote  #2

1537316892
Report to moderator
JoelKatz
Legendary
*
Offline Offline

Activity: 1582
Merit: 1004


Democracy is vulnerable to a 51% attack.


View Profile WWW
August 15, 2013, 01:30:54 AM
 #102

Encryption isn't weakened when the random number generator is bad like this?
It depends on the type of encryption and the exact details of the bug (which, to my knowledge, still haven't been released). Generally, programs on "small" devices tend to use asymmetric encryption as clients and then they really don't have anything to compromise.

I would be surprised if Bitcoin wallets were literally the only programs affected, but I wouldn't expect there to be very many others.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
bitpop
Legendary
*
Offline Offline

Activity: 2366
Merit: 1043


https://keybase.io/bitpop


View Profile WWW
August 15, 2013, 02:28:54 AM
 #103

Thankfully ssl wasn't affected. Hope my encfs isn't either.

Reputation  |  PGP  |  DigitalOcean  |  TorGuard  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
Bitmessage: BM-2cXN9j8NFT2n1FxDVQ6HQq4D4MZuuaBFyb
Jesse James
Newbie
*
Offline Offline

Activity: 29
Merit: 0


View Profile
August 15, 2013, 06:40:46 AM
 #104

Google posted an official post-mortem of the issue with SecureRandom as well as a fix.

However, I'm kinda confused. My read of the OpenSSL code would lead me to believe that it seeds itself [1] [2] with at least 32 bytes from /dev/urandom when you neglect to seed it yourself before hitting up RAND_bytes for randomness.

The proposed fix seeds OpenSSL manually from /dev/urandom (or if the OpenSSL-based SecureRandom isn't being used (non-JellyBean), simply serves randomness directly from /dev/urandom).

It's unclear to me how the proposed fix helps unless there is a flaw in OpenSSL's self seeding.  

Their fix does get rid of the Apache Harmony SecureRandom provider ... which, while bad (64 bits of entropy), mathematically could not have been the cause of the repeated signature nonces given their prevalence.

Even more confusing to me is how an OpenSSL self-seeding issue could lead to the particular pattern of repeated signature nonces observed ... in particular the majority of nonce repeats occurred in the context of the same transaction for sequential inputs. E.g. look at this offending transaction: 5 signatures; the first 2 share the same nonce as do the last two.  This transaction exhibits the exact same pattern.  For this bug to be responsible, the PRNG would literally need to spit out the same 32-bytes back to back. I don't see how this could happen with a thread-locked digest-based PRNG with singleton state (like OpenSSL's default) ... even if it's state was statically initialized.

I'm sure I'm missing something but if there are any other randomness nerds out there ... I'd love to hear your take.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1006


View Profile
August 15, 2013, 09:30:24 AM
 #105

Suffice it to say, the workarounds used in the bitcoin apps and the one given in the blog post will resolve the issue with OpenSSL. I presume there are reasons why the exact nature of the bug wasn't disclosed but yes, it can cause repeats in the RNG output.
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1750
Merit: 1001

Reverse engineer from time to time


View Profile
August 15, 2013, 12:26:16 PM
 #106

Google posted an official post-mortem of the issue with SecureRandom as well as a fix.

However, I'm kinda confused. My read of the OpenSSL code would lead me to believe that it seeds itself [1] [2] with at least 32 bytes from /dev/urandom when you neglect to seed it yourself before hitting up RAND_bytes for randomness.

The proposed fix seeds OpenSSL manually from /dev/urandom (or if the OpenSSL-based SecureRandom isn't being used (non-JellyBean), simply serves randomness directly from /dev/urandom).

It's unclear to me how the proposed fix helps unless there is a flaw in OpenSSL's self seeding.  

Their fix does get rid of the Apache Harmony SecureRandom provider ... which, while bad (64 bits of entropy), mathematically could not have been the cause of the repeated signature nonces given their prevalence.

Even more confusing to me is how an OpenSSL self-seeding issue could lead to the particular pattern of repeated signature nonces observed ... in particular the majority of nonce repeats occurred in the context of the same transaction for sequential inputs. E.g. look at this offending transaction: 5 signatures; the first 2 share the same nonce as do the last two.  This transaction exhibits the exact same pattern.  For this bug to be responsible, the PRNG would literally need to spit out the same 32-bytes back to back. I don't see how this could happen with a thread-locked digest-based PRNG with singleton state (like OpenSSL's default) ... even if it's state was statically initialized.

I'm sure I'm missing something but if there are any other randomness nerds out there ... I'd love to hear your take.
Darn, looks like my Android application may be affected after all, I am rolling with my own statically linked OpenSSL library 1.01e I think, so it's not being seeded properly?

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
Jesse James
Newbie
*
Offline Offline

Activity: 29
Merit: 0


View Profile
August 15, 2013, 12:34:25 PM
 #107

Suffice it to say, the workarounds used in the bitcoin apps and the one given in the blog post will resolve the issue with OpenSSL. I presume there are reasons why the exact nature of the bug wasn't disclosed but yes, it can cause repeats in the RNG output.

Thanks for the clarification.

I initially overlooked how the Google fix overrides the SecureRandom provider for all releases to date including the JellyBean ones.  I was distracted by the logic in applyOpenSSLFix() thinking it was what was responsible for curing SecureRandom ills on JellyBean ... but now I see it's kinda irrelevant in this context since the OpenSSLRandom provider is simply getting kicked to the curb for now.
JoelKatz
Legendary
*
Offline Offline

Activity: 1582
Merit: 1004


Democracy is vulnerable to a 51% attack.


View Profile WWW
August 15, 2013, 09:41:48 PM
 #108


Is there any link to the actual bug and the actual fix? I see descriptions of the affects of the bug and suggested workarounds, but not the actual bug itself nor the fix itself.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1000


bits of proof


View Profile WWW
August 16, 2013, 11:16:36 AM
 #109

And wouldn't that expose data encrypted by other apps to similar security issues?
No. The issue has nothing to do with exposing encrypted data but with signatures exposing private keys.

In contrary, this is a much bigger issue.

The Android PRNG must be extremely weak (say a joke) that this surfaced in the insignificant number of keys android wallets repeatedly used.

Encryption software usually use a key generated with PRNG, so do secure communication protocols. Pass phrases and asymmetric algorithms often only encrypt that pseudo random key. It is the pseudo random key that is really the secret, and is protecting the data.
Knowing the weakness of the PRNG makes brute forcing of encryption feasible since key space in question is reduced to a joke.

Therefore yes, a lot of encrypted data and communication (that was recorded in the past) is potentially affected by this "bug".
We will never know if it was gross negligence or NSA compliant engineering at work.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1006


View Profile
August 16, 2013, 01:54:50 PM
 #110

The underlying bug was reported by academics, it wasn't discovered internally by Google. So at some point they will publish a paper just like the guys who found the Harmony bugs did, and you will know the exact details.

Suffice it to say the failure was subtle. It isn't something easily found via code inspection. The NSA doesn't need to engage in monkey tricks anyway, they can just go pressure the providers that most people use or hack the endpoints and circumvent encryption entirely.
grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1000


bits of proof


View Profile WWW
August 16, 2013, 02:04:55 PM
 #111

Suffice it to say the failure was subtle. It isn't something easily found via code inspection.
Sounds like a sophisticated backdoor.

The NSA doesn't need to engage in monkey tricks anyway, they can just go pressure the providers that most people use or hack the endpoints and circumvent encryption entirely.
This is the first time you do not embrace encryption as a solution for a problem.
grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1000


bits of proof


View Profile WWW
August 16, 2013, 02:32:25 PM
 #112

It is known that the NSA employs a lot of bright guys, who certainly not only work on breaking code but also on how to prevent strong code in the first place.
A subtly but still seriously flawed PRNG planted into major operating systems could be a masterpiece of their effort.

It does not need complacency of Google to happen, just brilliance and social engineering on the other side.
Dougie
Full Member
***
Offline Offline

Activity: 209
Merit: 100


You are not special.


View Profile
August 16, 2013, 03:29:10 PM
 #113

Sue google for your losses! Maybe not. Pretty unfortunate really. I guess someone was bound to write a script to look for these transactions.

Lurking since 2011...
1J4DhU3q6RxxCTfAAcg5ExVK6FfxkmzkTH
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1006


View Profile
August 16, 2013, 03:39:46 PM
 #114

Encryption is a useful tool, I wouldn't want to be without it. It's obviously not a silver bullet. The cypherpunks in the 90's thought writing crypto software would bring about a social revolution. 20 years later we can see they were wrong - no social revolution happened and the state is larger and more powerful than ever. We exist in a world where totalitarian surveillance is the norm.

How much worse would things be without strong crypto? Worse, I'm sure, but significantly worse? Unclear.

I'm very skeptical when people claim Bitcoin will bring about a massive social revolution, or that governments can't control it. Satoshi explicitly disavowed such a claim and I agree with him. The US Government can terminate Bitcoin globally, if it so chooses, which is why extensive lobbying is so essential. It really lives or dies at the whims of some congressmen.

As to the Android RNG bug being an NSA plant - this theory doesn't hold water. There are two RNG failures. One, the Harmony bug published in the RSA paper, has been around for a long time but the Harmony authors couldn't have known Google would build a hugely successful OS on top of their work. For the NSA to somehow get a weak RNG into Harmony would mean they own a time machine and we might as well give up right now. The second failure only impacts Jellybean+ because the SecureRandom implementation was replaced with a shim over OpenSSL. It took less than a year for the problem to be found. Heck most phones don't even run Jellybean yet. If that's their grand plan to undermine crypto, then they suck at it.

grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1000


bits of proof


View Profile WWW
August 16, 2013, 04:24:20 PM
 #115

I'm very skeptical when people claim Bitcoin will bring about a massive social revolution, or that governments can't control it. Satoshi explicitly disavowed such a claim and I agree with him.
Yes, Bitcoin merely redistributes some riches from those who got lazy and trust their lobby to those who are innovative and trust their math.

The US Government can terminate Bitcoin globally, if it so chooses, which is why extensive lobbying is so essential. It really lives or dies at the whims of some congressmen.
I doubt they could achieve more than a few years of setback. I trust that there are congressmen who recognize, that this is a chance of redistributing on Wall Street, and would love to see that happen.

If that's their grand plan to undermine crypto, then they suck at it.
Cheesy Hope you are right.
justusranvier
Legendary
*
Offline Offline

Activity: 1400
Merit: 1006



View Profile WWW
August 16, 2013, 04:52:42 PM
 #116

I'm very skeptical when people claim Bitcoin will bring about a massive social revolution, or that governments can't control it. Satoshi explicitly disavowed such a claim and I agree with him. The US Government can terminate Bitcoin globally, if it so chooses, which is why extensive lobbying is so essential. It really lives or dies at the whims of some congressmen.
You've got the correlation/causation backwards. Bitcoin will not cause a social revolution. Bitcoin will be successful as a consequence of an ongoing social revolution.
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
August 16, 2013, 09:42:34 PM
 #117

If that's their grand plan to undermine crypto, then they suck at it.
Cheesy Hope you are right.
How do you guys know what was the objective? Maybe Android was just an unintended collateral damage?

Wasn't Crypto AG compromised through the similar means?

http://en.wikipedia.org/wiki/Crypto_AG

Personally I wouldn't know.

So I guess the answer lies somewhere in the changelogs for the affected projects.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
smolen
Hero Member
*****
Offline Offline

Activity: 525
Merit: 500


View Profile
August 17, 2013, 12:11:19 AM
 #118

So I guess the answer lies somewhere in the changelogs for the affected projects.
Hire incompetent manager, let him hire incompetent programmers, wait for suitable defect, withhold testcase from QA lab half globe away from your headquarter, enjoy plausible deniability.

Of course I gave you bad advice. Good one is way out of your price range.
molecular
Donator
Legendary
*
Offline Offline

Activity: 2562
Merit: 1006



View Profile
August 17, 2013, 06:34:33 AM
 #119

I know this is an extremely rough estimage, but guesstimating from Number of Transactions excl. popular we can speculate that roughly 20 kBTC have been moved from android wallets (assuming the spike is just that).

55 / 20k = 0.2% of funds stolen due to the bad RNG... could've been worse. I feel with the people who lost money, of course.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
piuk
Hero Member
*****
expert
Offline Offline

Activity: 910
Merit: 1001



View Profile WWW
August 17, 2013, 09:58:59 AM
 #120

I know this is an extremely rough estimage, but guesstimating from Number of Transactions excl. popular we can speculate that roughly 20 kBTC have been moved from android wallets (assuming the spike is just that).

55 / 20k = 0.2% of funds stolen due to the bad RNG... could've been worse. I feel with the people who lost money, of course.

As of today only 51% of users of the Blockchain.info app have upgraded to a patched release, if the pattern is similar with other apps a fair number of wallets might still be vulnerable. But you are right it definitely could have been worse.

Pages: « 1 2 3 4 5 [6] 7 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!