* [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected.
@ 2018-04-06 19:53 ketamine
2018-04-06 20:51 ` Matias Alejo Garcia
0 siblings, 1 reply; 10+ messages in thread
From: ketamine @ 2018-04-06 19:53 UTC (permalink / raw)
To: 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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected. 2018-04-06 19:53 [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected ketamine @ 2018-04-06 20:51 ` Matias Alejo Garcia 2018-04-09 21:11 ` Mustafa Al-Bassam 0 siblings, 1 reply; 10+ messages in thread From: Matias Alejo Garcia @ 2018-04-06 20:51 UTC (permalink / raw) To: ketamine, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2557 bytes --] 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! [-- Attachment #2: Type: text/html, Size: 3334 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected. 2018-04-06 20:51 ` Matias Alejo Garcia @ 2018-04-09 21:11 ` Mustafa Al-Bassam 2018-04-09 21:17 ` Mustafa Al-Bassam 2018-04-10 0:42 ` Jason Davies 0 siblings, 2 replies; 10+ messages in thread From: Mustafa Al-Bassam @ 2018-04-09 21:11 UTC (permalink / raw) To: Matias Alejo Garcia, Bitcoin Protocol Discussion, ketamine [-- Attachment #1: Type: text/plain, Size: 3178 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 5635 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected. 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 0:42 ` Jason Davies 1 sibling, 1 reply; 10+ messages in thread From: Mustafa Al-Bassam @ 2018-04-09 21:17 UTC (permalink / raw) To: Matias Alejo Garcia, Bitcoin Protocol Discussion, ketamine [-- Attachment #1: Type: text/plain, Size: 3422 bytes --] 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 > [-- Attachment #2: Type: text/html, Size: 6513 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected. 2018-04-09 21:17 ` Mustafa Al-Bassam @ 2018-04-09 23:39 ` Mustafa Al-Bassam 2018-04-10 8:51 ` Jason Davies 0 siblings, 1 reply; 10+ messages in thread From: Mustafa Al-Bassam @ 2018-04-09 23:39 UTC (permalink / raw) To: Bitcoin Protocol Discussion, Matias Alejo Garcia, ketamine [-- Attachment #1: Type: text/plain, Size: 4665 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 8668 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected. 2018-04-09 23:39 ` Mustafa Al-Bassam @ 2018-04-10 8:51 ` Jason Davies 2018-04-10 13:15 ` Aymeric Vitte 0 siblings, 1 reply; 10+ messages in thread From: Jason Davies @ 2018-04-10 8:51 UTC (permalink / raw) To: bitcoin-dev On 10 Apr 2018, at 00:39, mus@musalbas•com wrote: > 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. Yes, it looks like high-quality entropy via crypto.getRandomValues was only added in Tom Wu's latest version (v1.4) in July 2013. Note that even with v1.4, it still does not use high-quality entropy for Internet Explorer, because getRandomValues is provided under window.msCrypto for that browser. http://www-cs-students.stanford.edu/~tjw/jsbn/rng.js > 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. I think this is the real issue: even if high-quality entropy is utilised, the RNG is RC4-based, which is known to generate biased output. Finally, note that even Chrome used RC4 for crypto.getRandomValues at one point (as recently as 2015)! https://bugs.chromium.org/p/chromium/issues/detail?id=552749 -- Jason Davies, https://www.jasondavies.com/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected. 2018-04-10 8:51 ` Jason Davies @ 2018-04-10 13:15 ` Aymeric Vitte 2018-04-10 13:32 ` Jason Davies 0 siblings, 1 reply; 10+ messages in thread From: Aymeric Vitte @ 2018-04-10 13:15 UTC (permalink / raw) To: Jason Davies, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4787 bytes --] I used jsbn in the past, then I made some research too Apparently window.crypto.getRandomValues was introduced in jsbn mid 2012 (according to the wayback machine, but 2012/2013 does not make any difference, see below), was available in Chrome since 2011 (but indeed see "window.crypto.getRandomValues() uses a weak CSPRNG" https://bugs.chromium.org/p/chromium/issues/detail?id=552749 fixed *end *of 2015, funny to see that those that did specify the Webcrypto API did not implement it correctly...), in FF in 2013 (https://website-archive.mozilla.org/www.mozilla.org/firefox_releasenotes/en-US/firefox/21.0/releasenotes/) , in IE in 2013 and Safari ~2012/2013, at least that's the official dates for the Webcrypto API implementation, maybe something existed before, but it's not so easy to seek for the history The window.crypto.random check is in jsbn since the begining (2006) and only returns true for Netscape browsers before Netscape 5/6, ie Firefox (2000), see https://books.google.fr/books?id=UooAblGoGN8C&pg=PA85&lpg=PA85&dq=browser+appversion+4&source=bl&ots=dVijsOR0ov&sig=6SnElm56-bAvmGlKqUAdoGLAs2A&hl=fr&sa=X&ved=2ahUKEwirhtaqva_aAhUFchQKHQ4JCk4Q6AEwBXoECAAQcQ#v=onepage&q=browser%20appversion%204&f=false) From the existing tools, there was not only jsbn, everybody was using Math.random (sjcl, cryptoJS, forge, etc) with different implementations and everybody did put a note stating that it might be insecure with an "improvement to come" comment We can probably assume that nobody was using Netscape any longer when Bitcoin started The conclusion seems to be that at least all wallets generated by js tools inside browsers since bitcoin exists until 2011 are impacted by the Math.random weakness if applicable to the related implementations, the Math.random or RC4 (Chrome) weakness between 2011 and 2013, and RC4 weakness for Chrome users until end of 2015 And all wallets using jsbn are impacted by Math.random and RC4 until 2013 (or end 2015 for Chrome), then still by the RC4 fallback step after > Note that even with v1.4, it still does not use high-quality entropy for Internet Explorer, because getRandomValues is provided under window.msCrypto for that browser I don't know for that one, what was the issue? Le 10/04/2018 à 10:51, Jason Davies via bitcoin-dev a écrit : > On 10 Apr 2018, at 00:39, mus@musalbas•com wrote: > >> 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. > Yes, it looks like high-quality entropy via crypto.getRandomValues was only > added in Tom Wu's latest version (v1.4) in July 2013. > > Note that even with v1.4, it still does not use high-quality entropy for > Internet Explorer, because getRandomValues is provided under window.msCrypto > for that browser. > > http://www-cs-students.stanford.edu/~tjw/jsbn/rng.js > >> 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. > I think this is the real issue: even if high-quality entropy is utilised, the > RNG is RC4-based, which is known to generate biased output. > > Finally, note that even Chrome used RC4 for crypto.getRandomValues at one > point (as recently as 2015)! > > https://bugs.chromium.org/p/chromium/issues/detail?id=552749 > > -- > Jason Davies, https://www.jasondavies.com/ > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms [-- Attachment #2: Type: text/html, Size: 7591 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected. 2018-04-10 13:15 ` Aymeric Vitte @ 2018-04-10 13:32 ` Jason Davies 2018-04-10 13:50 ` Aymeric Vitte 0 siblings, 1 reply; 10+ messages in thread From: Jason Davies @ 2018-04-10 13:32 UTC (permalink / raw) To: Aymeric Vitte; +Cc: Bitcoin Protocol Discussion >> Note that even with v1.4, it still does not use high-quality entropy for >> Internet Explorer, because getRandomValues is provided under window.msCrypto >> for that browser. > > I don't know for that one, what was the issue? I simply meant that Internet Explorer implements the Web Cryptography API under window.msCrypto instead of window.crypto. Thus, unless msCrypto.getRandomValues is used, high-quality entropy will not have been used by any of these libraries under Internet Explorer. -- Jason Davies, https://www.jasondavies.com/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected. 2018-04-10 13:32 ` Jason Davies @ 2018-04-10 13:50 ` Aymeric Vitte 0 siblings, 0 replies; 10+ messages in thread From: Aymeric Vitte @ 2018-04-10 13:50 UTC (permalink / raw) To: Jason Davies; +Cc: Bitcoin Protocol Discussion Indeed, this impacts jsbn only normally since all others from the time getRandomValues was available are supposed to implement both Le 10/04/2018 à 15:32, Jason Davies a écrit : >>> Note that even with v1.4, it still does not use high-quality entropy for >>> Internet Explorer, because getRandomValues is provided under window.msCrypto >>> for that browser. >> I don't know for that one, what was the issue? > I simply meant that Internet Explorer implements the Web Cryptography API under > window.msCrypto instead of window.crypto. Thus, unless > msCrypto.getRandomValues is used, high-quality entropy will not have been used > by any of these libraries under Internet Explorer. > > -- > Jason Davies, https://www.jasondavies.com/ > -- Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected. 2018-04-09 21:11 ` Mustafa Al-Bassam 2018-04-09 21:17 ` Mustafa Al-Bassam @ 2018-04-10 0:42 ` Jason Davies 1 sibling, 0 replies; 10+ messages in thread From: Jason Davies @ 2018-04-10 0:42 UTC (permalink / raw) To: bitcoin-dev These issues all stem from the RC4-based RNG implementation (with insecure fallback entropy) in Tom Wu's jsbn library, published here: http://www-cs-students.stanford.edu/~tjw/jsbn/ Please refer to Tom Wu's URL, or this more up-to-date fork of Tom Wu's code (published to NPM): https://github.com/andyperlitch/jsbn -- my repository on GitHub was only ever intended to be a straight mirror of Tom Wu's code (created over 7 years ago!). I'll probably delete my mirror repository given that there are now better JavaScript bignum alternatives, and in light of this report. Jason > On 9 Apr 2018, at 22:11, mus@musalbas•com wrote: > > Here's the code in question: https://github.com/jasondavies/jsbn/pull/7 > > Best, > > Mustafa -- Jason Davies, http://www.jasondavies.com/ ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-04-10 13:50 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-04-06 19:53 [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected ketamine 2018-04-06 20:51 ` 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox