Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected. - Mustafa Al-Bassam

From: Mustafa Al-Bassam <mus@musalbas•com>
To: Matias Alejo Garcia <ematiu@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	ketamine@national•shitposting.agency
Subject: Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected.
Date: Mon, 9 Apr 2018 22:11:02 +0100	[thread overview]
Message-ID: <921edfdb-e0e5-8ce4-55d8-ba4e84ef633f@musalbas.com> (raw)
In-Reply-To: <CA+vKqYc3X6ZjVNXs0xgsLGekxPCTcLZj7t2vkyBOV_o=2C2qPA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3178 bytes --]

Here's the code in question: https://github.com/jasondavies/jsbn/pull/7

Best,

Mustafa


On 06/04/18 21:51, Matias Alejo Garcia via bitcoin-dev wrote:
> Source? 
>
> On Fri, Apr 6, 2018 at 4:53 PM, ketamine--- via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@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@lists•linuxfoundation.org
>     <mailto:bitcoin-dev@lists•linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
>
> -- 
> Matías Alejo Garcia
> @ematiu
> Roads? Where we're going, we don't need roads!
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #2: Type: text/html, Size: 5635 bytes --]