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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <secondisogeny@gmail.com>) id 1XGH5e-0003VO-65
for bitcoin-development@lists.sourceforge.net;
Sun, 10 Aug 2014 00:34:26 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.196 as permitted sender)
client-ip=209.85.160.196; envelope-from=secondisogeny@gmail.com;
helo=mail-yk0-f196.google.com;
Received: from mail-yk0-f196.google.com ([209.85.160.196])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XGH5d-0005rm-8M
for bitcoin-development@lists.sourceforge.net;
Sun, 10 Aug 2014 00:34:26 +0000
Received: by mail-yk0-f196.google.com with SMTP id 9so1341437ykp.7
for <bitcoin-development@lists.sourceforge.net>;
Sat, 09 Aug 2014 17:34:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.108.147 with SMTP id q19mr29948642yhg.27.1407630859818;
Sat, 09 Aug 2014 17:34:19 -0700 (PDT)
Received: by 10.170.36.82 with HTTP; Sat, 9 Aug 2014 17:34:19 -0700 (PDT)
Date: Sat, 9 Aug 2014 17:34:19 -0700
Message-ID: <CAFWhrvR+4wsMwzjvqb7w7XmhESagzc_0pvQuGx3Fn4qeWFbinA@mail.gmail.com>
From: second isogeny <secondisogeny@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=089e0160b5a85fdb2205003b99e8
X-Spam-Score: -0.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
(secondisogeny[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1XGH5d-0005rm-8M
Subject: [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 00:34:26 -0000
--089e0160b5a85fdb2205003b99e8
Content-Type: text/plain; charset=UTF-8
> Does anyone see any concerns when it comes to security of the proposed
> change?
Yes. This proposal is less secure.
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.
It is also an untimely proposal and would be inconsiderate other parties
who have done the work to produce correct and compatible implementations.
> In case I_L >= n assign I_L := I_L mod n.
This will make the selection of private keys uneven.
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.
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.
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.
> 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
There are many corner cases which must be handled in cryptographic
software.
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.
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.
--089e0160b5a85fdb2205003b99e8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> Does anyone see any concerns when it comes to securit=
y of the proposed<br>> change?<br><br>Yes.=C2=A0 This proposal is less s=
ecure.<br><br>It is incompatible in theory with existing implementations of=
the<br>
specification.=C2=A0 The incompatibility is also a potentially a security<b=
r>problem because it may cause users to believe a key is worthless when<br>=
it is not or to lose funds when they are unable to spend them.<br><br>It is=
also an untimely proposal and would be inconsiderate other parties<br>
who have done the work to produce correct and compatible implementations.<b=
r><br>> In case I_L >=3D n assign I_L :=3D I_L mod n.<br><br>This wil=
l make the selection of private keys uneven.<br><br>The unevenness is small=
and it is unlikely to very matter much but it<br>
is objectively less secure.=C2=A0 Future advances in cryptography may make<=
br>the distinction more important.=C2=A0 The change would eliminate any hop=
e of<br>the specification ever having provable security equal to random key=
s.<br>
<br>The bignum modulo operation also requires complex additional logic and =
is<br>just as likely to remain untested in implementations, though unit-tes=
ting<br>can test these cases by replacing the hash function.<br><br>Because=
of layering no suitable modulo may be available and an incorrect<br>
implementation could create a devastating weakness, like reflecting a<br>la=
rge class of keys to a small number of values.=C2=A0 A similar error would<=
br>be unlikely for an incorrect implementation of skipping and someone who<=
br>
managed to still fail would likely have failed either way.<br><br>> most=
of the implementations don't do the checking at all, because tjen<br>&=
gt; it's rather hard at application level to implement skipping logic. =
OTOH<br>
<br>There are many corner cases which must be handled in cryptographic<br>s=
oftware.<br><br>You must handle the point at infinity cases, you must handl=
e the signature<br>having a value of zero (or you leak the private key), in=
the point<br>
arithemetics you must handle the special case of adding colinear points.<br=
><br>If someone is unprepared to deal with these and many other complicatio=
ns<br>they may want to leave writing this kind of software for other people=
.<br>
<br></div>
--089e0160b5a85fdb2205003b99e8--
|
