public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mustafa Al-Bassam <mus@musalbas.com>
To: Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	Matias Alejo Garcia <ematiu@gmail.com>,
	ketamine@national.shitposting.agency
Subject: Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected.
Date: Tue, 10 Apr 2018 00:39:15 +0100	[thread overview]
Message-ID: <69fb5cc4-7b3d-e23d-2b7e-cddcd7b2877b@musalbas.com> (raw)
In-Reply-To: <010e34a3-f9cf-fba1-5482-de06bc350d64@musalbas.com>

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

The original disclosure didn't contain any information about the library
in question, so I did some digging.

I think that the vulnerability disclosure is referring to a pre-2013
version of jsbn, a JavaScript crypto library. Before it used the CSRNG
in the Web Crypto API, it tried to use nsIDOMCrypto, but incorrectly did
a string comparison when checking the browser version.

In practice though, this doesn't really matter, because
navigator.appVersion < "5" returns true anyway for old browsers. The
real issue is that modern browsers don't have window.crypto.random
defined, so Bitcoin wallets using a pre-2013 version of jsbn may not be
using a CSPRNG, when run on a modern browser.

As is noted though, even if a CSPRNG is used, the library passes the
output of the CSPRNG through RC4, which generates some biased bits,
leading to possible private key recovery.


On 09/04/18 22:17, Mustafa Al-Bassam via bitcoin-dev wrote:
>
> And specifically, here's a version of it that uses Arcfour:
> https://gist.github.com/jonls/5230850
>
>
> On 09/04/18 22:11, Mustafa Al-Bassam wrote:
>>
>> 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
>>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

  reply	other threads:[~2018-04-09 23:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-06 19:53 [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected ketamine
2018-04-06 20:51 ` Matias Alejo Garcia
2018-04-09 21:11   ` Mustafa Al-Bassam
2018-04-09 21:17     ` Mustafa Al-Bassam
2018-04-09 23:39       ` Mustafa Al-Bassam [this message]
2018-04-10  8:51         ` Jason Davies
2018-04-10 13:15           ` Aymeric Vitte
2018-04-10 13:32             ` Jason Davies
2018-04-10 13:50               ` Aymeric Vitte
2018-04-10  0:42     ` Jason Davies

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=69fb5cc4-7b3d-e23d-2b7e-cddcd7b2877b@musalbas.com \
    --to=mus@musalbas.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=ematiu@gmail.com \
    --cc=ketamine@national.shitposting.agency \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox