I’ve learn the article from Unciphered about it, a number of occasions, and nonetheless fail to grasp it
It mainly says that wallets generated by BitcoinJs entrance finish library from 2011 to 2015 are weak due to the poor randomness technology. Particularly these generated between Might 4, 2011 to March 2012
But it surely’s actually imprecise on explaining what the precise exploit is. It may very well be simply summarized as: it used Math.random() for randomness earlier than March 2014, and it’s a dangerous operate
Let us take a look at the preliminary commit from March 4, 2011 : eckey.js is used for producing the non-public key, whereas rng.js and prng4.js within the jsbn folder are used for harvesting randomness.
rng.js
If rng_pool
is just not already initialized, it’s crammed with random values from Math.random()
whereas(rng_pptr < rng_psize) { // extract some randomness from Math.random()
t = Math.flooring(65536 * Math.random());
rng_pool[rng_pptr++] = t >>> 8;
rng_pool[rng_pptr++] = t & 255;
}
Math.random()
in response to the article has the cycle of two^60 values earlier than they repeat. The article additionally mentions that it fails fashionable benchmark assessments, however I am unsure about them
Is Math.random()
the entire weak point of the story? What’s the weak point truly about?
Later, the time in milliseconds is seeded to the pool
operate rng_seed_time() {
rng_seed_int(new Date().getTime());
}
And later for
SecureRandom.prototype.nextBytes = rng_get_bytes;
we initialize the state, and move the pool as the important thing into the RC4 cipher
rng_state = prng_newstate();
rng_state.init(rng_pool);
from prng4.js
prng4.js
which creates a 256 worth array
this.S = new Array();
and fills it with the loop
for(i = 0; i < 256; ++i) {
j = (j + this.S[i] + key[i % key.length]) & 255;
t = this.S[i];
this.S[i] = this.S[j];
this.S[j] = t;
}
eckey.js
eckey.js makes use of SecureRandom() and creates our non-public key
var rng = new SecureRandom();
....
this.priv = ECDSA.getBigRandom(n);
However once more, this tells us subsequent to nothing in regards to the precise vulnerability and what assaults could be used. Unciphered’s article means that if we now have GUID or IV (I assume that is a public key?), then we will do the work with simply 2^32 to 2^64 values (2^48 mostly)
Additionally, unsure in regards to the clicks being added within the entropy pool, aside from:
<physique onClick='rng_seed_time();' onKeyPress="rng_seed_time();">
remark.
In what means, different issues are added into entropy pool aside from the preliminary timestamp seed?