rich1.0npub1p6uknnmm7wknvg9cq5wqsf7ulpsrdzd6zt6qw707y5t05fuzvfdsx8etdehttps://nostr.ae/npub1p6uknnmm7wknvg9cq5wqsf7ulpsrdzd6zt6qw707y5t05fuzvfdsx8etdenjumphttps://nostr.ae📅 Original date posted:2018-04-06 📝 Original message:Source? On Fri, Apr 6, 2018 at 4:53 PM, ketamine--- via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > A significant number of past and current cryptocurrency products > contain a JavaScript class named SecureRandom(), containing both > entropy collection and a PRNG. The entropy collection and the RNG > itself are both deficient to the degree that key material can be > recovered by a third party with medium complexity. There are a > substantial number of variations of this SecureRandom() class in > various pieces of software, some with bugs fixed, some with additional > bugs added. Products that aren't today vulnerable due to moving to > other libraries may be using old keys that have been previously > compromised by usage of SecureRandom(). > > > The most common variations of the library attempts to collect entropy > from window.crypto's CSPRNG, but due to a type error in a comparison > this function is silently stepped over without failing. Entropy is > subsequently gathered from math.Random (a 48bit linear congruential > generator, seeded by the time in some browsers), and a single > execution of a medium resolution timer. In some known configurations > this system has substantially less than 48 bits of entropy. > > The core of the RNG is an implementation of RC4 ("arcfour random"), > and the output is often directly used for the creation of private key > material as well as cryptographic nonces for ECDSA signatures. RC4 is > publicly known to have biases of several bits, which are likely > sufficient for a lattice solver to recover a ECDSA private key given a > number of signatures. One popular Bitcoin web wallet re-initialized > the RC4 state for every signature which makes the biases bit-aligned, > but in other cases the Special K would be manifest itself over > multiple transactions. > > > Necessary action: > > * identify and move all funds stored using SecureRandom() > > * rotate all key material generated by, or has come into contact > with any piece of software using SecureRandom() > > * do not write cryptographic tools in non-type safe languages > > * don't take the output of a CSPRNG and pass it through RC4 > > - > 3CJ99vSipFi9z11UdbdZWfNKjywJnY8sT8 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Matías Alejo Garcia @ematiu Roads? Where we're going, we don't need roads! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180406/7cdc248c/attachment-0001.html>