summaryrefslogtreecommitdiff
path: root/50/e7821697c51f2126aa5940866d8363ee6251ae
blob: 9b8c15b1b5c66fe8df20a59a68354d5ab0f89129 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <a86551@outlook.com>) id 1VaYmJ-0003KG-Vz
	for bitcoin-development@lists.sourceforge.net;
	Sun, 27 Oct 2013 22:25:48 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of outlook.com
	designates 65.55.90.237 as permitted sender)
	client-ip=65.55.90.237; envelope-from=a86551@outlook.com;
	helo=snt0-omc4-s34.snt0.hotmail.com; 
Received: from snt0-omc4-s34.snt0.hotmail.com ([65.55.90.237])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1VaYmJ-0007n0-42 for bitcoin-development@lists.sourceforge.net;
	Sun, 27 Oct 2013 22:25:47 +0000
Received: from SNT151-W90 ([65.55.90.200]) by snt0-omc4-s34.snt0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 27 Oct 2013 15:25:41 -0700
X-TMN: [6afln0UZ5U2bSgDZgoUcPt7zR5h5wOXx]
X-Originating-Email: [a86551@outlook.com]
Message-ID: <SNT151-W902926CDE9837FF83699C5820F0@phx.gbl>
From: Andres Home <a86551@outlook.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Date: Sun, 27 Oct 2013 22:25:41 +0000
Importance: Normal
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Oct 2013 22:25:41.0420 (UTC)
	FILETIME=[785236C0:01CED363]
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(a86551[at]outlook.com)
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [65.55.90.237 listed in list.dnswl.org]
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
	digit (a86551[at]outlook.com)
X-Headers-End: 1VaYmJ-0007n0-42
Subject: [Bitcoin-development] Advisory: PHP library Bitcoin SCI weak key
	generation
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 27 Oct 2013 22:25:48 -0000

For those developers who are using the Bitcoin SCI library (maybe others to=
o=2C I=0A=
found two total and could only make contact with one)=2C I would advise tha=
t you=0A=
review how your software handles private key creation.=0A=
=0A=
Up until today=2C the Bitcoin SCI library used the Mersenne Twister PRNG or=
 the=0A=
GMP library's PRNG directly to generate private keys. This has been somewha=
t =0A=
resolved in the most recent version (October 27th)=2C but only for the =0A=
createNewMiniKey() function. Even if you haven't been using this library=2C=
 it =0A=
would be a fine oportunity to check your key generation functions if you do=
 not =0A=
interface directly with bitcoind. =0A=
=0A=
Affected keys have 32bits of entropy=2C possibly up to 56bits depending on =
the =0A=
build of PHP=2C a low enough amount that would allow GPU based attacks on k=
eys=0A=
in the lower ranges.=0A=
=0A=
=0A=
I do not know how many keys have been created using either function=0A=
.=0A=
I also don't share the authors optimism that this isn't an issue. 		 	   		=
  =