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

[Mustafa Al-Bassam via bitcoin-dev]

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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Mustafa Al-Bassam via bitcoin-dev]

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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Mustafa Al-Bassam via bitcoin-dev]

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
>> > > 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] AsicBoost

[Mustafa Al-Bassam via bitcoin-dev]

Alternatively scenario: it will cause a sudden increase of Bitcoin mines
in countries where the algorithm is not patented, possibly causing a
geographical decentralization of miners from countries that already have
a lot of miners like China (if it is patented in China).

On 01/04/16 10:00, Peter Todd via bitcoin-dev wrote:
> On Thu, Mar 31, 2016 at 09:41:40PM -0700, Timo Hanke via bitcoin-dev wrote:
>> Hi.
>>
>> I'd like to announce a white paper that describes a very new and
>> significant algorithmic improvement to the Bitcoin mining process which has
>> never been discussed in public before. The white paper can be found here:
>>
>> http://www.math.rwth-aachen.de/~Timo.Hanke/AsicBoostWhitepaperrev5.pdf
> What steps are you going to take to make sure that this improvement is
> available to all ASIC designers/mfgs on a equal opportunity basis?
>
> The fact that you've chosen to patent this improvement could be a
> centralization concern depending on the licensing model used. For example, one
> could imagine a licensing model that gave one manufacture exclusive rights.
>
>
>
> ___
> 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

Re: [bitcoin-dev] BIP 2 promotion to Final

[Mustafa Al-Bassam via bitcoin-dev]

On 10/03/16 15:59, Jorge Timón wrote:
>
>
> On Mar 10, 2016 16:51, "Mustafa Al-Bassam via bitcoin-dev"
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> > I think in general this sounds like a good definition for a hard-fork
> > becoming active. But I can envision a situation where someone will try
> > to be annoying about it and point to one instance of one buyer and one
> > seller using the blockchain to buy and sell from each other, or set
> one up.
>
> And all the attacker will achieve is preventing a field on a text file
> on github from moving from "active" to "final".
> Seems pretty stupid. Why would an attacker care so much about this? Is
> there any way the attacker can make gains or harm bitcoin with this
> attack?
>
It's extremely naive to think that just because you can't think of an
incentive for a reason for an attack to do this, an attacker will never
to do this. There are many people that would be willing to spend some
time to cause some trouble for the enjoyment of it, if the attack is
free to execute.

The fact that it takes very little time and effort to prevent a BIP from
reaching final status, means that in an base of millions of users it's
guaranteed that some disgruntled or bored person out there will attack
it, even if it's for the lulz.

To reasonably expect that any hark fork - including an uncontroversial
one - will be adapted by every single person in a ecosystem of millions
of people, is wishful thinking and the BIP may as well say "hard fork
BIPs shall never reach final status."
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 2 promotion to Final

[Mustafa Al-Bassam via bitcoin-dev]

On 10/03/16 00:53, Luke Dashjr wrote:
> On Thursday, March 10, 2016 12:29:16 AM Mustafa Al-Bassam wrote:
>>> the soft-fork does not become Final for as long as such a hard-fork
>>> has potentially-majority support, or at most three months.
>> This wording is awkward. What is "potentially-majority"?
> A group that is large enough that it may constitute a majority.
> How can I reword this better/clearer?
"potentially has majority support"?
>
>>> A hard-fork BIP requires adoption from the entire Bitcoin economy,
>>> particularly including those selling desirable goods and services in
>>> exchange for bitcoin payments, as well as Bitcoin holders who wish to
>>> spend or would spend their bitcoins (including selling for other
>>> currencies) differently in the event of such a hard-fork.
>> What if one shop owner, for example, out of thousands, doesn't adapt the
>> hard-fork? It is expected, and should perhaps be encouraged, for a small
>> minority to not accept a hard fork, but by the wording of the BIP
>> ("entire Bitcoin economy"), one shop owner can veto a hard-fork.
> It's not the hard-fork they can veto (in this context, anyway), but the 
> progression of the BIP Status field. However, one shop cannot operate in a 
> vacuum: if they are indeed alone, they will soon find themselves no longer 
> selling in exchange for bitcoin payments, as nobody else would exist willing 
> to use the previous blockchain to pay them. If they are no longer selling, 
> they cease to meet the criteria here enabling their veto.
I think in general this sounds like a good definition for a hard-fork
becoming active. But I can envision a situation where someone will try
to be annoying about it and point to one instance of one buyer and one
seller using the blockchain to buy and sell from each other, or set one up.

> Luke

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses

[Mustafa Al-Bassam via bitcoin-dev]

It would be nice to decouple the venue, but even BIP 1 gives that
control to whoever controls the mailing list: "Following a discussion,
the proposal should be sent to the bitcoin-dev list and the BIP editor
with the draft BIP." (BIP 1)

A neater way to do it might be to replace references to the mailing list
with "public discussion medium" where "medium" can be defined as
something like any discussion forum frequented by the wider development
community, like the pull requests section of the BIP repo, conferences, etc.

On 02/02/16 15:58, Gavin Andresen via bitcoin-dev wrote:
> On Mon, Feb 1, 2016 at 5:53 PM, Luke Dashjr via bitcoin-dev
>  > wrote:
>
> I've completed an initial draft of a BIP that provides
> clarifications on the
> Status field for BIPs, as well as adding the ability for public
> comments on
> them, and expanding the list of allowable BIP licenses.
>
> 
> https://github.com/luke-jr/bips/blob/bip-biprevised/bip-biprevised.mediawiki
>
> I plan to open discussion of making this BIP an Active status
> (along with BIP
> 123) a month after initial revisions have completed. Please
> provide any
> objections now, so I can try to address them now and enable
> consensus to be
> reached.
>
>  
>
> I like the more concrete definitions of the various statuses.
>
> I don't like the definition of "consensus".  I think the definition
> described gives too much centralized control to whoever controls the
> mailing list and the wiki.
>
> -- 
> --
> Gavin Andresen
>
>
>
> ___
> 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

Re: [bitcoin-dev] BIP 2 promotion to Final

[Mustafa Al-Bassam via bitcoin-dev]

> the soft-fork does not become Final for as long as such a hard-fork
has potentially-majority support, or at most three months.
This wording is awkward. What is "potentially-majority"?

>A hard-fork BIP requires adoption from the entire Bitcoin economy,
particularly including those selling desirable goods and services in
exchange for bitcoin payments, as well as Bitcoin holders who wish to
spend or would spend their bitcoins (including selling for other
currencies) differently in the event of such a hard-fork.
What if one shop owner, for example, out of thousands, doesn't adapt the
hard-fork? It is expected, and should perhaps be encouraged, for a small
minority to not accept a hard fork, but by the wording of the BIP
("entire Bitcoin economy"), one shop owner can veto a hard-fork.

Mustafa

On 08/03/16 19:04, Luke Dashjr via bitcoin-dev wrote:
> It has been about 1 month since BIP 2 finished receiving comments, so I 
> believe it is an appropriate time to begin the process of moving it to Final 
> Status. Toward this end, I have opened a pull request:
>
> https://github.com/bitcoin/bips/pull/350
>
> The current requirement for this is that "the reference implementation is 
> complete and accepted by the community". Given the vagueness of this 
> criteria, 
> I intend to move forward applying BIP 2's more specific criteria to itself:
>
>> A process BIP may change status from Draft to Active when it achieves rough
>> consensus on the mailing list. Such a proposal is said to have rough
>> consensus if it has been open to discussion on the development mailing list
>> for at least one month, and no person maintains any unaddressed
>> substantiated objections to it. Addressed or obstructive objections may be
>> ignored/overruled by general agreement that they have been sufficiently
>> addressed, but clear reasoning must be given in such circumstances.
> Furthermore, there is a reference implementation in the mentioned PR.
>
> Please review the latest draft BIP and provide any objections ASAP.
> If there are no outstanding objections on 2016 April 9th, I will consider the 
> current draft to have reached rough consensus and update its Status to Final 
> by merging the PR.
>
> Thanks,
>
> Luke
> ___
> 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