summaryrefslogtreecommitdiff
path: root/98/d0ae05f469c731e95d27a7b1a20a0f93258c24
blob: 90726a7c37c1d9b3b58b32e427c638161a8a0d3f (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
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <elombrozo@gmail.com>) id 1XGHo4-0001Xv-4g
	for bitcoin-development@lists.sourceforge.net;
	Sun, 10 Aug 2014 01:20:20 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.173 as permitted sender)
	client-ip=209.85.192.173; envelope-from=elombrozo@gmail.com;
	helo=mail-pd0-f173.google.com; 
Received: from mail-pd0-f173.google.com ([209.85.192.173])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XGHo2-00070Y-VJ
	for bitcoin-development@lists.sourceforge.net;
	Sun, 10 Aug 2014 01:20:20 +0000
Received: by mail-pd0-f173.google.com with SMTP id w10so8888587pde.18
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 09 Aug 2014 18:20:13 -0700 (PDT)
X-Received: by 10.66.245.140 with SMTP id xo12mr33158798pac.38.1407633613163; 
	Sat, 09 Aug 2014 18:20:13 -0700 (PDT)
Received: from [192.168.1.108] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202])
	by mx.google.com with ESMTPSA id 5sm10762781pds.12.2014.08.09.18.20.10
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sat, 09 Aug 2014 18:20:11 -0700 (PDT)
Content-Type: multipart/signed;
	boundary="Apple-Mail=_0C2F2A54-EE8A-41AC-8CCC-9E22ABFC1B1C";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CAFWhrvR+4wsMwzjvqb7w7XmhESagzc_0pvQuGx3Fn4qeWFbinA@mail.gmail.com>
Date: Sat, 9 Aug 2014 18:20:09 -0700
Message-Id: <501F55C1-6307-487B-91D8-9CC0193DA747@gmail.com>
References: <CAFWhrvR+4wsMwzjvqb7w7XmhESagzc_0pvQuGx3Fn4qeWFbinA@mail.gmail.com>
To: second isogeny <secondisogeny@gmail.com>
X-Mailer: Apple Mail (2.1510)
X-Spam-Score: -1.6 (-)
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
	(elombrozo[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XGHo2-00070Y-VJ
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP32 - invalidation
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, 10 Aug 2014 01:20:20 -0000


--Apple-Mail=_0C2F2A54-EE8A-41AC-8CCC-9E22ABFC1B1C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Does bitcoin properly handle the case of a hash collision? no - because =
it is considered too unlikely. The case of I_L >=3D n is also =
astronomically unlikely, so it's more a matter of improved performance =
and simpler data structures under expected circumstances and taking that =
less than 1 in 2^127 chance that it will fail, in which case we can =
recover by moving everything over to a new tree.

-Eric Lombrozo



On Aug 9, 2014, at 5:34 PM, second isogeny <secondisogeny@gmail.com> =
wrote:

> > Does anyone see any concerns when it comes to security of the =
proposed
> > change?
>=20
> Yes.  This proposal is less secure.
>=20
> It is incompatible in theory with existing implementations of the
> specification.  The incompatibility is also a potentially a security
> problem because it may cause users to believe a key is worthless when
> it is not or to lose funds when they are unable to spend them.
>=20
> It is also an untimely proposal and would be inconsiderate other =
parties
> who have done the work to produce correct and compatible =
implementations.
>=20
> > In case I_L >=3D n assign I_L :=3D I_L mod n.
>=20
> This will make the selection of private keys uneven.
>=20
> The unevenness is small and it is unlikely to very matter much but it
> is objectively less secure.  Future advances in cryptography may make
> the distinction more important.  The change would eliminate any hope =
of
> the specification ever having provable security equal to random keys.
>=20
> The bignum modulo operation also requires complex additional logic and =
is
> just as likely to remain untested in implementations, though =
unit-testing
> can test these cases by replacing the hash function.
>=20
> Because of layering no suitable modulo may be available and an =
incorrect
> implementation could create a devastating weakness, like reflecting a
> large class of keys to a small number of values.  A similar error =
would
> be unlikely for an incorrect implementation of skipping and someone =
who
> managed to still fail would likely have failed either way.
>=20
> > most of the implementations don't do the checking at all, because =
tjen
> > it's rather hard at application level to implement skipping logic. =
OTOH
>=20
> There are many corner cases which must be handled in cryptographic
> software.
>=20
> You must handle the point at infinity cases, you must handle the =
signature
> having a value of zero (or you leak the private key), in the point
> arithemetics you must handle the special case of adding colinear =
points.
>=20
> If someone is unprepared to deal with these and many other =
complications
> they may want to leave writing this kind of software for other people.
>=20
> =
--------------------------------------------------------------------------=
----
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--Apple-Mail=_0C2F2A54-EE8A-41AC-8CCC-9E22ABFC1B1C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJT5sjJAAoJEAA1EyJsW9n+zvgP/RKwczorptcZHBJkyQ4fu9QJ
DJNYEsC1CtqBwwaUG0mqtLTQ/3kyaXE1NPLEnQZadn5e77CWbZ+olvzev2/1Vg/A
kXdV/YVv2NpmxXgY1PMX1wxeJ+F0k4EKZ0erFFN5BB3oFWKsjDteC+UlyyUXnuiX
hqkKaA4jJf7B9p7kjSpwwW5r52oNrREuvxEbjCZ281aQwo5BdXtk9EE/jmgGejLS
DvPUDEE04S8wL+pc0+saQlTccvgX5kI4rjVC7nHtvKa6GCpxgTtRk3NOF/TqWdd/
yebb9crD3lhK3SFxftec+z4bFZ0lvVS4MHuDRCtFJMpmdPMNVJVT+qDiJyVAf6JD
WBA/UhsA0hemg42eaj1iahtUCsm45LPCPJ6mhOU5FUNSFspl6kXf5Lzn6TXe4RL4
NzvwzDaED8eOC4pLFxQB4FFnpg/PBzW54ETF0nkvh6zMhXjzbqqxfTOi/x7lXjh6
7Vk8zmtcdU8zpkYzRJ5s8o9y6VBix8RZp7GsV5iripI3Px024VyBHZz/Usuqbrop
ascgdG6Dy8/sOD6Yc4p7cpxyzRfVwSaTQWjsSljqss/9bucOabswwqkQK5RfTVEr
vN9gOhlQIajTg7j0n3rkyQK85tG8oU7Qa1gEy/0eNIaRgJvhYyLaefAQbQiMWoLt
yGmXUrBduHQ1rVFlsP/y
=BYJj
-----END PGP SIGNATURE-----

--Apple-Mail=_0C2F2A54-EE8A-41AC-8CCC-9E22ABFC1B1C--