<unnamed>

Public Key

npub1uerrhhkc2vxew5xsmw3p3gt888mmydwf6vlxjypng8p23rc0m6kqgu2z6z

Profile Code

nprofile1qqswv33mmmv9xrvh2rgdhgsc59nnnaajxhyax0nfzqe5rs4g3u8aatqpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qvmsxmf

Publishing to

relay.nostr.net

Last Notes

2023-06-07 18:11:33 UTC

- reply

📅 Original date posted:2018-04-09
📝 Original message: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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180409/a678381a/attachment.html>

2023-06-07 18:11:33 UTC

- reply

📅 Original date posted:2018-04-09
📝 Original message: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 at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180409/1bd0330e/attachment.html>

2023-06-07 18:11:33 UTC

- reply

📅 Original date posted:2018-04-09
📝 Original message: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 at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180410/a4f2aca5/attachment-0001.html>

2023-06-07 17:50:03 UTC

- reply

📅 Original date posted:2016-04-04
📝 Original message: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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160405/41cbbc99/attachment.html>