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
183
184
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1X74jJ-00047c-OT for bitcoin-development@lists.sourceforge.net;
Tue, 15 Jul 2014 15:33:21 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of m.gmane.org
designates 80.91.229.3 as permitted sender)
client-ip=80.91.229.3;
envelope-from=gcbd-bitcoin-development@m.gmane.org;
helo=plane.gmane.org;
Received: from plane.gmane.org ([80.91.229.3])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1X74jH-0006rP-Rc
for bitcoin-development@lists.sourceforge.net;
Tue, 15 Jul 2014 15:33:21 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1X74jA-0001lg-VO for bitcoin-development@lists.sourceforge.net;
Tue, 15 Jul 2014 17:33:12 +0200
Received: from f052021167.adsl.alicedsl.de ([78.52.21.167])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Tue, 15 Jul 2014 17:33:12 +0200
Received: from andreas by f052021167.adsl.alicedsl.de with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-development@lists.sourceforge.net>;
Tue, 15 Jul 2014 17:33:12 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Tue, 15 Jul 2014 17:32:59 +0200
Message-ID: <lq3hjc$s4a$1@ger.gmane.org>
References: <CANEZrP3ZzCBohXWZmZxE=ofP74Df4Hd-hCLH6jYn=JKbiqNQXA@mail.gmail.com> <CAObn+gfbH61kyv_ttT4vsQuNFRWLB5H3xaux7GQ0co82ucO_eA@mail.gmail.com>
<CAJHLa0MMaQU7Xu=vo0Z2C5h5M-Oa9_a648yDRrw6UR=r81X66w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: f052021167.adsl.alicedsl.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <CAJHLa0MMaQU7Xu=vo0Z2C5h5M-Oa9_a648yDRrw6UR=r81X66w@mail.gmail.com>
X-Enigmail-Version: 1.5.2
X-Spam-Score: -0.4 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [80.91.229.3 listed in list.dnswl.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
1.1 DKIM_ADSP_ALL No valid author signature,
domain signs all mail
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1X74jH-0006rP-Rc
Subject: Re: [Bitcoin-development] BIP 38 NFC normalisation issue
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: Tue, 15 Jul 2014 15:33:21 -0000
Can you provide the rationale for standard practice? For example, why
should whitespace be allowed? I regularly use trim() on any passphrase
(or other input ftm).
So what's the action point? Should we amend the spec to filter control
characters? That would get rid of the \u0000 problem.
On 07/15/2014 05:17 PM, Jeff Garzik wrote:
> Unicode guarantees that null-terminated strings still work. U+0000
> terminates a unicode (or C) string. strlen() gets the string byte
> count. mbstowcs() gets the character count.
>
> Whitespace can be problematic, but should be allowed. Control
> characters should be filtered. Emoticons probably cannot be filtered
> without substandard approaches such as character blacklists, a road
> you do not want to travel.
>
> (all this is simply standard practice)
>
>
> On Tue, Jul 15, 2014 at 9:07 AM, Eric Winer <enwiner@gmail.com> wrote:
>> I don't know for sure if the test vector is correct NFC form. But for what
>> it's worth, the Pile of Poo character is pretty easily accessible on the
>> iPhone and Android keyboards, and in this string it's already in NFC form
>> (f09f92a9 in the test result). I've certainly seen it in usernames around
>> the internet, and wouldn't be surprised to see it in passphrases entered on
>> smartphones, especially if the author of a BIP38-compatible app includes a
>> (possibly ill-advised) suggestion to have your passphrase "include special
>> characters".
>>
>> I haven't seen the NULL character on any smartphone keyboards, though - I
>> assume the iOS and Android developers had the foresight to know how much
>> havoc that would wreak on systems assuming null-terminated strings. It
>> seems unlikely that NULL would be in a real-world passphrase entered by a
>> sane user.
>>
>>
>> On Tue, Jul 15, 2014 at 8:03 AM, Mike Hearn <mike@plan99.net> wrote:
>>>
>>> [+cc aaron]
>>>
>>> We recently added an implementation of BIP 38 (password protected private
>>> keys) to bitcoinj. It came to my attention that the third test vector may be
>>> broken. It gives a hex version of what the NFC normalised version of the
>>> input string should be, but this does not match the results of the Java
>>> unicode normaliser, and in fact I can't even get Python to print the names
>>> of the characters past the embedded null. I'm curious where this normalised
>>> version came from.
>>>
>>> Given that "pile of poo" is not a character I think any sane user would
>>> put into a passphrase, I question the value of this test vector. NFC form is
>>> intended to collapse things like umlaut control characters onto their prior
>>> code point, but here we're feeding the algorithm what is basically garbage
>>> so I'm not totally surprised that different implementations appear to
>>> disagree on the outcome.
>>>
>>> Proposed action: we remove this test vector as it does not represent any
>>> real world usage of the spec, or if we desperately need to verify NFC
>>> normalisation I suggest using a different, more realistic test string, like
>>> Zürich, or something written in Thai.
>>>
>>>
>>>
>>> Test 3:
>>>
>>> Passphrase ϓ␀𐐀💩 (\u03D2\u0301\u0000\U00010400\U0001F4A9; GREEK UPSILON
>>> WITH HOOK, COMBINING ACUTE ACCENT, NULL, DESERET CAPITAL LETTER LONG I, PILE
>>> OF POO)
>>> Encrypted key: 6PRW5o9FLp4gJDDVqJQKJFTpMvdsSGJxMYHtHaQBF3ooa8mwD69bapcDQn
>>> Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF
>>> Unencrypted private key (WIF):
>>> 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4
>>> Note: The non-standard UTF-8 characters in this passphrase should be NFC
>>> normalized to result in a passphrase of0xcf9300f0909080f09f92a9 before
>>> further processing
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
|
