MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 06 Apr 2018 21:53:13 +0200
From: ketamine@national.shitposting.agency
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <84976adb75bef1dfdb12b98c19811278@national.shitposting.agency>
User-Agent: Roundcube Webmail/1.3.3
Subject: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(),
 numerous cryptocurrency products affected.
Precedence: list

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