From: ketamine@national.shitposting.agency
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected.
Date: Fri, 06 Apr 2018 21:53:13 +0200 [thread overview]
Message-ID: <84976adb75bef1dfdb12b98c19811278@national.shitposting.agency> (raw)
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
next reply other threads:[~2018-04-06 20:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-06 19:53 ketamine [this message]
2018-04-06 20:51 ` [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected 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
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=84976adb75bef1dfdb12b98c19811278@national.shitposting.agency \
--to=ketamine@national.shitposting.agency \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/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