Twenty Year Anniversary

KETAMINE: SecureRandom() Weakness

KETAMINE: SecureRandom() Weakness
Posted Apr 13, 2018

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.

tags | advisory, javascript
MD5 | 893d474d121cd29fb6bb8f8f0d4d294c

KETAMINE: SecureRandom() Weakness

Change Mirror Download
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


Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

Want To Donate?


Bitcoin: 18PFeCVLwpmaBuQqd5xAYZ8bZdvbyEWMmU

File Archive:

August 2018

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Aug 1st
    19 Files
  • 2
    Aug 2nd
    17 Files
  • 3
    Aug 3rd
    16 Files
  • 4
    Aug 4th
    1 Files
  • 5
    Aug 5th
    1 Files
  • 6
    Aug 6th
    19 Files
  • 7
    Aug 7th
    15 Files
  • 8
    Aug 8th
    9 Files
  • 9
    Aug 9th
    7 Files
  • 10
    Aug 10th
    10 Files
  • 11
    Aug 11th
    1 Files
  • 12
    Aug 12th
    0 Files
  • 13
    Aug 13th
    14 Files
  • 14
    Aug 14th
    0 Files
  • 15
    Aug 15th
    0 Files
  • 16
    Aug 16th
    0 Files
  • 17
    Aug 17th
    0 Files
  • 18
    Aug 18th
    0 Files
  • 19
    Aug 19th
    0 Files
  • 20
    Aug 20th
    0 Files
  • 21
    Aug 21st
    0 Files
  • 22
    Aug 22nd
    0 Files
  • 23
    Aug 23rd
    0 Files
  • 24
    Aug 24th
    0 Files
  • 25
    Aug 25th
    0 Files
  • 26
    Aug 26th
    0 Files
  • 27
    Aug 27th
    0 Files
  • 28
    Aug 28th
    0 Files
  • 29
    Aug 29th
    0 Files
  • 30
    Aug 30th
    0 Files
  • 31
    Aug 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2018 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close