Reused R values again - page 9. | Bitcointalksearch.org

lontivero

full member

Activity: 164

Merit: 126

Amazing times are coming

Quote from: lontivero on December 15, 2014, 03:30:56 PM

Quote from: CIYAM on December 15, 2014, 10:36:20 AM

people who have been the victim of blockchain.info's incredible incompetence.

Are you sure this is incredible incompetence? The transactions are no reusing the same R values but there are an (unknown) patterm instead. That cannot be incompetence nor accident, it has to be programmed as it is in bc.i by developers (very talented developers indeed).

Quote from: bcearl on December 16, 2014, 10:01:44 AM

https://www2.informatik.hu-berlin.de/~verbuech/klepto-ecdsa/

Very good finding @bcearl, that paper describes what I think could happend (because of incompetence or not) and the conclusion is hard to swallow.

CIYAM

legendary

Activity: 1890

Merit: 1072

Ian Knowles - CIYAM Lead Developer

I have not made an uninitialised variable mistake in over 10 years (and I code in C++ where this can be a serious issue).

For code to have been released into production with such a mistake is *clearly incompetence* and I am not talking about the particular dev (everyone makes mistakes) but by the organisation itself (where was the code review?).

You can't promote yourself to be a secure website for storing money if you can't even manage to audit simple code issues like initialisation.

My recommendation would be not to use blockchain.info for storing funds - they are clearly not up to the job of actually securing it.

JorgeStolfi

hero member

Activity: 910

Merit: 1003

Quote from: bcearl on December 16, 2014, 10:01:44 AM

BTW., if someone with skill would manipulate the RNG intentionally, he would do it this way:

https://bitcointalksearch.org/topic/how-perfect-offline-wallets-can-still-leak-bitcoin-private-keys-883793
https://www2.informatik.hu-berlin.de/~verbuech/klepto-ecdsa/
http://www.reddit.com/r/Bitcoin/comments/2p2kcd/how_perfect_offline_wallets_can_still_leak/

Wow...

Understandably, harware wallet manufacturers tend to present their products as 100% safe, and hide or dismiss their risks. But, at the very least, you must trust the manufacturer (and trust that they didn't hire that programmer that BCI just fired Grin

), as well as all the people who may have access to it along the path from the factory to your pocket. As customers grow confident in such devices, the payoff for an attack via malicious fake devices could be huge, and criminals may invest proportionally in carrying out the attack.

amaclin

legendary

Activity: 1260

Merit: 1019

Quote

BTW., if someone with skill would manipulate the RNG intentionally, he would do it this way:

... aaaaaand if skull not enough, he will fail with the error in his javascript, which gives security hole to "Joe Who" instead of himself.

(just wondering about dates. on the December,5 this was published
on December,8 - bc.i failed
in my country we have a proverb: "at catcher the animal runs")

bcearl

full member

Activity: 168

Merit: 103

BTW., if someone with skill would manipulate the RNG intentionally, he would do it this way:

https://bitcointalksearch.org/topic/how-perfect-offline-wallets-can-still-leak-bitcoin-private-keys-883793
https://www2.informatik.hu-berlin.de/~verbuech/klepto-ecdsa/
http://www.reddit.com/r/Bitcoin/comments/2p2kcd/how_perfect_offline_wallets_can_still_leak/

bcearl

full member

Activity: 168

Merit: 103

Quote from: johoe on December 16, 2014, 08:55:48 AM

Or did just someone read the security alert and saved his money?

This clearly makes more sense to me since all the work of re-engineering the RNG is not worth the few satoshis left. You did a good job saving the big share.

Aceman

newbie

Activity: 17

Merit: 0

Is it wrong to think of Johoe somewhat as a hero to the BTC community?

JorgeStolfi

hero member

Activity: 910

Merit: 1003

Quote from: johoe on December 16, 2014, 08:55:48 AM

If someone would have done it intentionally he would have swept the 590 BTC that I found this week-end.

I do not think malice is likely, but I won't exclude it either. There may be several reasons why a malicious programmer failed to sweep those coins. E. g. after the bug was discovered, he may have been afraid of being caught (especially if he is some BCI staff, hence a natural suspect, hence with his internet connections under watch).

johoe

full member

Activity: 217

Merit: 238

The bug that is present since September is different. It is still going on and I can distinguish it from bc.i clearly.

If someone would have done it intentionally he would have swept the 590 BTC that I found this week-end.

I will hopefully be able to sweep the last addresses in a few hours.

But someone else is sweeping; I'm not the only one who broke the RNG.
https://blockchain.info/address/1MKSWH9pShsLdV54cRLDQ9JKarsjXK4ms5

Or did just someone read the security alert and saved his money?

amaclin

legendary

Activity: 1260

Merit: 1019

Quote

Is that so? I thought that the earlier occurrences in the blockchain were due to some other project (Counterparty?), not BCI.

Counterparty bug was in April.
This bug (as noticed johoe) appeared first time in september.
I haven't checked it, but can check my data.
As I said above - this bug appeared when somebody sent btc to exchange with mixing them through bc.i "sharedcoin" engine

upd:
johoe continues to sweep
1723624c2809b62e9a6f11283c9681a1ed0828ca902518dd102509c48a87be7d:0 to 1HuqM18GMVaLxTRGdmSgytzVYnhRzu7U68 [4.89755711]
on my radars right now

JorgeStolfi

hero member

Activity: 910

Merit: 1003

Quote from: amaclin on December 16, 2014, 06:52:13 AM

Quote

The bug was caught after a few hours, perhaps he did not have enough time to get home and start sweeping.

This bug is visible in blockchain since september.

Is that so? I thought that the earlier occurrences in the blockchain were due to some other project (Counterparty?), not BCI.

itod

legendary

Activity: 1974

Merit: 1075

^ Will code for Bitcoins

Quote from: amaclin on December 16, 2014, 06:31:51 AM

Quote

... let alone it is impossible because every commit to the code is tracked on the GitHub...

No.
Have a look here: http://www.reddit.com/r/Bitcoin/comments/2oltp9/warning_blockchaininfos_javascript_verifier_is/

BC.I put the bogus sources from their local base, not from github.
Later they fixed bugs and commited this to github.
So, code with bug did not ever present on github.

Well they almost certainly used Git with their local codebase, so if that can't be tracked on GitHub, can be tracked on their local Git. Chances not knowing who committed the patch with omitted variable initialization is ~~almost~~ non-existent.

Quote from: JorgeStolfi on December 16, 2014, 06:43:58 AM

The programmer who did the commit was innocent, but a malicious colleague or hacker broke into his computer and removed the initialization statement without him noticing.

Doing this in corporate environment without being noticed and investigated after - do you really think anyone can try this in security sensitive office environment and not ending indicted with criminal offense? If something like that happens inside an office nobody continues to work until the situation is investigated to the end.

amaclin

legendary

Activity: 1260

Merit: 1019

Quote

The bug was caught after a few hours, perhaps he did not have enough time to get home and start sweeping.

This bug is visible in blockchain since september.
Somebody sometimes sent his btc to btc-e through sharedcoin (for anonymity transfers?).
(it is very easy to track all transfers to btc-e - I can tell you how to do it)

I think that it was one of the developers of bc.i used bogus environment.

JorgeStolfi

hero member

Activity: 910

Merit: 1003

Quote from: itod on December 16, 2014, 03:33:08 AM

Quote from: JorgeStolfi on December 15, 2014, 11:04:57 PM

There may not have been malice by the Blockchain.info management, but maybe there was malice by some programmer who had access to the code and intended to sweep the affected addresses once they had enough bitcoins in them . While the bug looks just like an accidental omission, that appearance may be intentional too.

And the 500+ BTC johoe swept was not enough for that mythical in-house programmer, he was waiting for more hoping nobody will notice reused R values on the blockchain? What you are saying makes no sense, let alone it is impossible because every commit to the code is tracked on the GitHub and such a criminal programmer would be caught. There was no malice from the Blockchain.info side. Just look at the bug, uninitiated variable used as array index failing that array to empty without throwing an exception, it looks like a bug.

The bug was caught after a few hours, perhaps he did not have enough time to get home and start sweeping.

Why would a thief settle for 500 BTC if he could wait a day and sweep 5'000 or more.

There was a claim of 100 BTC being swept by someone else than @johoe. A thief would avoid sweeping small amounts since the more people affected the greater the risk of the attack being discovered and blocked.

A malicious programmer would have tried to make the bug look like an accidental error, to excuse himself.

The programmer who did the commit was innocent, but a malicious colleague or hacker broke into his computer and removed the initialization statement without him noticing.

There are many possibilities... but I admit: as Napoleon said, never attribute to malice what can be satisfactorily explained by incompetence...

amaclin

legendary

Activity: 1260

Merit: 1019

Quote

... let alone it is impossible because every commit to the code is tracked on the GitHub...

No.
Have a look here: http://www.reddit.com/r/Bitcoin/comments/2oltp9/warning_blockchaininfos_javascript_verifier_is/

BC.I put the bogus sources from their local base, not from github.
Later they fixed bugs and commited this to github.
So, code with bug did not ever present on github.

itod

legendary

Activity: 1974

Merit: 1075

^ Will code for Bitcoins

Quote from: JorgeStolfi on December 15, 2014, 11:04:57 PM

There may not have been malice by the Blockchain.info management, but maybe there was malice by some programmer who had access to the code and intended to sweep the affected addresses once they had enough bitcoins in them . While the bug looks just like an accidental omission, that appearance may be intentional too.

And the 500+ BTC johoe swept was not enough for that mythical in-house programmer, he was waiting for more hoping nobody will notice reused R values on the blockchain? What you are saying makes no sense, let alone it is impossible because every commit to the code is tracked on the GitHub and such a criminal programmer would be caught. There was no malice from the Blockchain.info side. Just look at the bug, uninitiated variable used as array index failing that array to empty without throwing an exception, it looks like a bug.

JorgeStolfi

hero member

Activity: 910

Merit: 1003

Quote from: johoe on December 15, 2014, 04:53:35 PM

I know this pattern and I know how it was "programmed in". It was a bug: one variable was not initialized.

It's bad that this was not caught before it went into production. Testing a random number generator is of course hard. How can you see whether a random number is really random.

It is incompetence to have a software updating protocol that lets such a bug go through. The random number generator is one of the absolutely critical parts of the bitcoin protocol and (as you notice) very hard to debug by testing. A change in that code (or in any part of the code, actually) should have been reviewed with extreme care by many competent eyes before being put in production.

Quote from: johoe on December 15, 2014, 04:53:35 PM

You can also ask, who profits? This incident has given bc.i bad publicity, a lot of work to handle support request, and some bitcoins have been stolen.

There may not have been malice by the Blockchain.info management, but maybe there was malice by some programmer who had access to the code and intended to sweep the affected addresses once they had enough bitcoins in them . While the bug looks just like an accidental omission, that appearance may be intentional too.

bcearl

full member

Activity: 168

Merit: 103

Quote from: johoe on December 15, 2014, 04:53:35 PM

Testing a random number generator is of course hard.

You are right, but this one was so bad that people got the same k several times. They should have detected.

But yes, it was a bug. Patters are totally normal. It does not require skill to write a program with an output following a pattern. The hard task is to write a random generator that does NOT follow a pattern.

johoe

full member

Activity: 217

Merit: 238

Quote from: lontivero on December 15, 2014, 03:30:56 PM

Are you sure this is incredible incompetence? The transactions are no reusing the same R values but there are an (unknown) patterm instead. That cannot be incompetence nor accident, it has to be programmed as it is in bc.i by developers (very talented developers indeed).

I know this pattern and I know how it was "programmed in". It was a bug: one variable was not initialized.

It's bad that this was not caught before it went into production. Testing a random number generator is of course hard. How can you see whether a random number is really random. One needs to restart the program several times to get a collision. In this case a unit test or some additional debugging outputs checking that the changed code behaves correctly would have helped, though. The javascript code is sometimes a bit messy and the fact that javascript has no type-checking makes such problems harder to avoid.

You can also ask, who profits? This incident has given bc.i bad publicity, a lot of work to handle support request, and some bitcoins have been stolen. Of course, I profited from this a lot - but I'm sure bc.i doesn't think I caused it.

PS: I'm still seeing week R values in some transactions! Most are okay, but someone is still using the bad RNG.

lontivero

full member

Activity: 164

Merit: 126

Amazing times are coming

it does matter because bc.i is THE site/wallet now and users without a technical background use theirs services so, if they introduced this hidden pattern in the R values then we (all) are in troubles. Bitcoin doesn't need another MtGox's incident like .

Topic: Reused R values again - page 9. (Read 121128 times)