<p>I have not seen a thorough technical review. However, after reading about the issue, my understanding is that the issue related to reusing the same <code>k</code> nonce value for <a href="http://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm" rel="nofollow">ECDSA</a>, not in generating private keys.</p>

<p>Blockchain.info's blog post about the issue is <a href="http://blog.blockchain.com/2014/12/08/blockchain-info-security-disclosure/" rel="nofollow">here</a>.</p>

<p>Blockchain.info's GitHub commit that fixed the issue is <a href="https://github.com/blockchain/My-Wallet/commit/98d5a7ca59ef04d06ac6aee468634b12975a0f5c" rel="nofollow">here</a>.</p>

<p>The individual who noticed its effect on transactions is a forum user by the name of "johoe" and you can see the discussion that unfolded beginning with <a href="https://bitcointalk.org/index.php?topic=581411.msg9774894#msg9774894" rel="nofollow">this post</a>.</p>

<p>It is a known requirement for ECDSA that for each signature with a particular private key, a unique <code>k</code> value must be used, otherwise with even just two signatures of the same <code>k</code> the private key used in the signature can be recovered. This issue is described in depth <a href="http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/" rel="nofollow">here</a>.</p>

<p><a href="https://github.com/filosottile/blockchainr" rel="nofollow">Here</a> is an open source project that discovers vulnerable private keys on the blockchain. <a href="https://conference.hitb.org/hitbsecconf2014kul/materials/D1T1%20-%20Filippo%20Valsorda%20-%20Exploiting%20ECDSA%20Failures%20in%20the%20Bitcoin%20Blockchain.pdf" rel="nofollow">This slide show</a> discusses the issue, the open source project, and some investigation into which wallets are susceptible (Blockchain.info is among the unsafe ones listed).</p>

<p>The solution for this has been known for a while: use <a href="http://tools.ietf.org/rfc/rfc6979.txt" rel="nofollow">RFC 6979</a>.</p>

CC BY-SA 3.0
2014-12-12T14:42:17.360Z
2014-12-12T14:42:17.360Z
Chuck Batson
<p>I the news I read this:</p>

<blockquote>
  <p>The firm was forced to make a security disclosure on its blog and on
  Reddit, admitting that a development error had led to a problem with
  the generation of private keys. Private keys (effectively the private
  addresses used to hold bitcoin) were generated with a low degree of
  entropy, making them easy for attackers to retrieve.</p>
</blockquote>

<p>Is there a detailed analysis available of what exactly happened or perhaps you could share your thoughts on this? I understand a concept of information entropy just want to know what should be done and what should be avoided to achieve a high degree of entropy.</p>

CC BY-SA 3.0
2014-12-11T23:40:04.393Z
What firm? Do you have a link to the article?
Chuck Batson
CC BY-SA 3.0
2014-12-12T07:56:04.670Z
http://www.coindesk.com/blockchain-addresses-security-debacle-need-better/
src091
<security>
Technical analysis of Blockchain.info security breach
src091
# Technical analysis of Blockchain.info security breach

(Asked by: username_0 on 2014-12-11)

I the news I read this:

> The firm was forced to make a security disclosure on its blog and on
> Reddit, admitting that a development error had led to a problem with
> the generation of private keys. Private keys (effectively the private
> addresses used to hold bitcoin) were generated with a low degree of
> entropy, making them easy for attackers to retrieve.

Is there a detailed analysis available of what exactly happened or perhaps you could share your thoughts on this? I understand a concept of information entropy just want to know what should be done and what should be avoided to achieve a high degree of entropy.

**Tags:** security

> **Comments:**
> **username_1**: What firm? Do you have a link to the article?  
> **username_0**: http://www.coindesk.com/blockchain-addresses-security-debacle-need-better/  

---

## 1 answers

### Answer by username_1 on 2014-12-12. Score: 1 | Accepted answer

I have not seen a thorough technical review. However, after reading about the issue, my understanding is that the issue related to reusing the same `k` nonce value for [ECDSA](http://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm), not in generating private keys.

Blockchain.info's blog post about the issue is [here](http://blog.blockchain.com/2014/12/08/blockchain-info-security-disclosure/).

Blockchain.info's GitHub commit that fixed the issue is [here](https://github.com/blockchain/My-Wallet/commit/98d5a7ca59ef04d06ac6aee468634b12975a0f5c).

The individual who noticed its effect on transactions is a forum user by the name of "johoe" and you can see the discussion that unfolded beginning with [this post](https://bitcointalk.org/index.php?topic=581411.msg9774894#msg9774894).

It is a known requirement for ECDSA that for each signature with a particular private key, a unique `k` value must be used, otherwise with even just two signatures of the same `k` the private key used in the signature can be recovered. This issue is described in depth [here](http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/).

[Here](https://github.com/filosottile/blockchainr) is an open source project that discovers vulnerable private keys on the blockchain. [This slide show](https://conference.hitb.org/hitbsecconf2014kul/materials/D1T1%20-%20Filippo%20Valsorda%20-%20Exploiting%20ECDSA%20Failures%20in%20the%20Bitcoin%20Blockchain.pdf) discusses the issue, the open source project, and some investigation into which wallets are susceptible (Blockchain.info is among the unsafe ones listed).

The solution for this has been known for a while: use [RFC 6979](http://tools.ietf.org/rfc/rfc6979.txt).


---

