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

[Matias Alejo Garcia via bitcoin-dev]

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

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

[ketamine--- via bitcoin-dev]

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

Re: [bitcoin-dev] Signature bundles

[Jim Posen via bitcoin-dev]

I'll just mention that non-interactive one-way aggregation with BLS
signatures solves this problem rather nicely.

On Mon, Apr 2, 2018 at 10:31 PM, Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Anthony Towns via bitcoin-dev 
> writes:
> > If you've got one bundle that overpays fees and another that underpays,
> > you can safely combine the two only if you can put a SIGHASH_ALL sig in
> > the one that overpays (otherwise miners could just make their own tx of
> > just the overpaying bundle).
>
> This is a potential problem, yes :( And I'm not sure how to solve it,
> unless you do some crazy thing like commit to a set of keys which are
> allowed to bundle, which kind of defeats the generality of outsourcing.
>
> > This could replace SINGLE|ANYONECANPAY at a cost of an extra couple of
> > witness bytes.
> >
> > I think BUNDLESTART is arguably redundant -- you could just infer
> > BUNDLESTART if you see an INBUNDLE flag when you're not already in
> > a bundle. Probably better to have the flag to make parsing easier,
> > so just have the rule be BUNDLESTART is set for precisely the first
> > INBUNDLE signature since the last bundle finished.
>
> Indeed.
>
> >> One of the issues we've struck with lightning is trying to guess future
> >> fees for commitment transactions: we can't rely on getting another
> >> signature from our counterparty to increase fees.  Nor can we use
> >> parent-pays-for-child since the outputs we can spend are timelocked.
> >
> > That doesn't quite work with the HTLC-Success/HTLC-Timeout transactions
> > though, does it? They spend outputs from the commitment transaction
> > and need to be pre-signed by your channel partner in order to ensure
> > the output address is correct -- but if the commitment transaction gets
> > bundled, its txid will change, so it can't be pre-signed.
>
> Not without SIGHASH_NOINPUT, no.
>
> > FWIW, a dumb idea I had for this problem was to add a zero-value
> > anyone-can-spend output to commitment transactions, that can then be
> > used with CPFP to bump the fees. Not very nice for UTXO bloat if fee
> > bumping isn't needed though, and I presume it would fail to pass the
> > dust threshold...
>
> Yeah, let's not do that.
>
> > I wonder if it would be plausible to have after-the-fact fee-bumping
> > via special sighash flags at the block level anyway though. Concretely:
> > say you have two transactions, X and Y, that don't pay enough in fees,
> > you then provide a third transaction whose witness is [txid-for-X,
> > txid-for-Y, signature committing to (txid-for-X, txid-for-Y)], and can
> > only be included in a block if X and Y are also in the same block. You
> > could make that fairly concise if you allowed miners to replace
> txid-for-X
> > with X's offset within the block (or the delta between X's txnum and the
> > third transaction's txnum), though coding that probably isn't terribly
> > straightforward.
>
> What would it spend though?  Can't use an existing output, so this
> really needs to be stashed in an *output script*, say a zero-amount
> output which is literally a push of txids, and is itself unspendable.
>
> ... 
>
> That's pretty large though, and it's non-witness data (though
> discardable).  How about 'OP_NOP4  '?
> Then the miner just bundles those tx all together?
>
> Cheers,
> Rusty.
> ___
> 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