Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 03212DD9 for ; Mon, 9 Apr 2018 21:20:06 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from algebra.musalbas.com (algebra.musalbas.com [163.172.28.238]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0E555625 for ; Mon, 9 Apr 2018 21:20:04 +0000 (UTC) Received: from [10.15.0.6] (unknown [10.15.0.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by algebra.musalbas.com (Postfix) with ESMTPSA id 4055812C0187; Mon, 9 Apr 2018 23:11:03 +0200 (CEST) To: Matias Alejo Garcia , Bitcoin Protocol Discussion , ketamine@national.shitposting.agency References: <84976adb75bef1dfdb12b98c19811278@national.shitposting.agency> From: Mustafa Al-Bassam Message-ID: <921edfdb-e0e5-8ce4-55d8-ba4e84ef633f@musalbas.com> Date: Mon, 9 Apr 2018 22:11:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8F74355E8DB4C218F4B5704F" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=musalbas.com; s=dkim; t=1523308263; bh=fo6kVVzwayAFRyR6v6vfs+3jflkjPcNPQ9exaXx+qco=; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type; b=r5OsTK+pbBMKqiSQqX+OgrlZZ5+DSKG5v3q8mL7kp8AFpG5vsxf+K04Z0+78ORnJQG54az6l5MsLgmcIDLkFVuvctbfI3WcrRtHWcrmnacysSF0NN19eVJFEn8jiAA81Jqieonqbg6bL4bCRF6IIbm502aYf0zj3NZ7EauJvKvs= X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 21:20:06 -0000 This is a multi-part message in MIME format. --------------8F74355E8DB4C218F4B5704F Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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 > > 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 > > 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 --------------8F74355E8DB4C218F4B5704F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

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> 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
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

--------------8F74355E8DB4C218F4B5704F--