Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected.
On 10 Apr 2018, at 00:39, m...@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
Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected.
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, m...@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 ___ 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.
>> 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-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.
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Few questions regarding ListTransaction
Hi, I have few questions regarding ListTransaction RPC call and I hope you can help me. Documentation for the RPC call is here: https://bitcoin.org/en/developer-reference#listtransactions 1. What does it mean for a transaction ( with 0 confirmations ) to be *trusted* or not? There is such field in the response of ListTransaction As far as I know bitcoin - nothing is trusted unless there are some numbers of confirmations. How does this value is set to true or false? 2. When does *confirmations* can be -1 ( conflicted )? What does it mean to have conflicted transaction? Is it about Transaction Malleability? Double Spend? or both? 3. *walletconflicts*. What if I add watch-only address to my bitcoind process. This address will not be a part of my wallet. Now, someone will pay me to this address and someone else will make Transaction Malleability ( for the sake of example, lets assume this second one will be confirmed, not the original one ). Will I get a first transaction in *walletconflicts* array when ListTransaction will return me second transaction in the response? Thank you in advance! ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Few questions regarding ListTransaction
2) -1 doesn't mean conflicted, it means the transaction is not only unconfirmed buy depends on another unconfirmed transaction. 1) Depends on what you mean by trusted. If you are giving the user online access to something that costs you next to nothing to revoke if there is a problem later, no problem. 0-conf is great. If you are pre-pairing shipments and will be able to pull the box from the ship stream if there is a problem, also no problem. If you are sending some other non-reversible thing like crypto, then you might want to be careful. It really depends on the value of your things and your tolerance of risk. In my opinion, an zero-conf transaction is way way better than a credit card preauth or a check in hand. On Tue, Apr 10, 2018 at 1:34 PM Maksim Solovjov via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > > I have few questions regarding ListTransaction RPC call and I hope you can > help me. > Documentation for the RPC call is here: > https://bitcoin.org/en/developer-reference#listtransactions > > 1. What does it mean for a transaction ( with 0 confirmations ) to be > *trusted* or not? > There is such field in the response of ListTransaction > As far as I know bitcoin - nothing is trusted unless there are some > numbers of confirmations. > How does this value is set to true or false? > > 2. When does *confirmations* can be -1 ( conflicted )? > What does it mean to have conflicted transaction? > Is it about Transaction Malleability? Double Spend? or both? > > 3. *walletconflicts*. What if I add watch-only address to my bitcoind > process. > This address will not be a part of my wallet. > Now, someone will pay me to this address and someone else will make > Transaction Malleability ( for the sake of example, lets assume this second > one will be confirmed, not the original one ). > Will I get a first transaction in *walletconflicts* array when > ListTransaction will return me second transaction in the response? > > Thank you in advance! > ___ > 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] Few questions regarding ListTransaction
On Wed, Apr 11, 2018 at 5:29 AM, Maksim Solovjov via bitcoin-dev wrote: > 1. What does it mean for a transaction ( with 0 confirmations ) to be > trusted or not? It is trusted if (1) it is final (i.e. it can't be replaced), (2) it is not in a block that was reorged out (negative confirmation count), (3) the 'spend zero conf change' option is set, (4) it is in the mempool, and (5) all inputs are from us. > 2. When does confirmations can be -1 ( conflicted )? > What does it mean to have conflicted transaction? > Is it about Transaction Malleability? Double Spend? or both? A transaction is conflicted if a different transaction exists that spends the same inputs. A transaction gets -N confirmations if it is mined in a block, and that block is orphaned away, and a different transaction is mined in the new block so that the transaction becomes a double spend. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Few questions regarding ListTransaction
Clarification on one part below: On Wed, Apr 11, 2018 at 2:21 PM, Karl-Johan Alm wrote: > On Wed, Apr 11, 2018 at 5:29 AM, Maksim Solovjov via bitcoin-dev > wrote: >> 1. What does it mean for a transaction ( with 0 confirmations ) to be >> trusted or not? > > It is trusted if (1) it is final (i.e. it can't be replaced), (2) it > is not in a block that was reorged out (negative confirmation count), > (3) the 'spend zero conf change' option is set, (4) it is in the > mempool, and (5) all inputs are from us. "can't be replaced" here means it cannot be replaced through conventional means. It is always possible to replace a transaction that has not yet been confirmed, e.g. by asking a miner to mine a conflicting transaction directly. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
