Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1X76oV-0003Pl-R4 for bitcoin-development@lists.sourceforge.net; Tue, 15 Jul 2014 17:46:51 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of midnightdesign.ws designates 50.87.144.70 as permitted sender) client-ip=50.87.144.70; envelope-from=boydb@midnightdesign.ws; helo=gator3054.hostgator.com; Received: from gator3054.hostgator.com ([50.87.144.70]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1X76oU-0008VH-2Y for bitcoin-development@lists.sourceforge.net; Tue, 15 Jul 2014 17:46:51 +0000 Received: from [209.85.215.43] (port=55194 helo=mail-la0-f43.google.com) by gator3054.hostgator.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1X74QN-0001Ut-II for bitcoin-development@lists.sourceforge.net; Tue, 15 Jul 2014 10:13:47 -0500 Received: by mail-la0-f43.google.com with SMTP id hr17so3978118lab.30 for ; Tue, 15 Jul 2014 08:13:44 -0700 (PDT) X-Gm-Message-State: ALoCoQnVMnSP3FuwMyDTrksCRTDqmMZc7K6pZjHUEg6TDH2EutbbE5Xj4uV8Cu5mrQobLfHhjyyU MIME-Version: 1.0 X-Received: by 10.112.160.105 with SMTP id xj9mr18664292lbb.2.1405437224694; Tue, 15 Jul 2014 08:13:44 -0700 (PDT) Received: by 10.152.30.106 with HTTP; Tue, 15 Jul 2014 08:13:44 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Jul 2014 10:13:44 -0500 Message-ID: From: Brooks Boyd To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11c2ab5c884c4204fe3cda91 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3054.hostgator.com X-AntiAbuse: Original Domain - lists.sourceforge.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - midnightdesign.ws X-BWhitelist: no X-Source-IP: 209.85.215.43 X-Exim-ID: 1X74QN-0001Ut-II X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (mail-la0-f43.google.com) [209.85.215.43]:55194 X-Source-Auth: midnight X-Email-Count: 0 X-Source-Cap: bWlkbmlnaHQ7bWlkbmlnaHQ7Z2F0b3IzMDU0Lmhvc3RnYXRvci5jb20= X-Spam-Score: -0.5 (/) 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 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1X76oU-0008VH-2Y 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 17:46:52 -0000 --001a11c2ab5c884c4204fe3cda91 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I was part of adding in that test vector, and I think it's a good test vector since it is an extreme edge-case of the current definition: If the BIP38 proposal allows any password that can be in UTF-8, NFC normalized form, those characters cover the various edge cases (combining characters, null character, astral range) that if your implementation doesn't handle, then it can't really be said to be "BIP38-compatible/compliant", right? The "passphrase" in the test vector is NOT in NFC form; that's the point. Whatever implementation gets designed has to assume the input is not already NFC-normalized and needs to handle/sanitize that input before further processing. To test your implementation for compliance, you should not be inputting the NFC-normalized bytestring as the password input, you should be entering the original passphrase as the test. My original pull request for this change (https://github.com/bitcoin/bips/pull/29) shows a Python and a NodeJS way to input that test vector password as intended. Some input devices may already handle the input as NFC, which is great, but per the BIP38 proposal, that shouldn't be assumed, so various implementations are cross-compatible. If one implementation assumes the input is already NFC, they may encode/decode the password incorrectly, and lock a user out of their wallet. Android allows different user keyboards to be used, so I'm guessing there's one somewhere that allows manual entry of unicode codepoints that could be used to enter a null character, and with the next version of iOS, Apple devices will also get custom keyboard options, too, so even if the default Apple keyboard does NFC-form properly, other developers' keyboards may not. So while it is an extreme edge case, that is not very likely to be used as a "real password" by any user, that's what test vectors are for: to test for the edge case that you might not have expected and handled in your implementation. Brooks On Tue, Jul 15, 2014 at 8:07 AM, Eric Winer 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 ap= p > 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 wrote: > >> [+cc aaron] >> >> We recently added an implementation of BIP 38 (password protected privat= e >> keys) to bitcoinj. It came to my attention that the third test vector ma= y >> 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 nam= es >> of the characters past the embedded null. I'm curious where this normali= sed >> 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 for= m >> 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 appe= ar >> 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, l= ike >> Z=C3=BCrich, or something written in Thai. >> >> >> >> Test 3: >> >> - Passphrase =CF=92=CC=81=E2=90=80=F0=90=90=80=F0=9F=92=A9 (\u03D2\u0= 301\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 of0xcf9300f0909080f09f92a= 9 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 > > --001a11c2ab5c884c4204fe3cda91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was part of adding in that test vector, and I think it&#= 39;s a good test vector since it is an extreme edge-case of the current def= inition: If the BIP38 proposal allows any password that can be in UTF-8, NF= C normalized form, those characters cover the various edge cases (combining= characters, null character, astral range) that if your implementation does= n't handle, then it can't really be said to be "BIP38-compatib= le/compliant", right?

The "passphrase" in the test vector is NOT in NFC = form; that's the point. Whatever implementation gets designed has to as= sume the input is not already NFC-normalized and needs to handle/sanitize t= hat input before further processing. To test your implementation for compli= ance, you should not be inputting the NFC-normalized bytestring as the pass= word input, you should be entering the original passphrase as the test. My = original pull request for this change (https://github.com/bitcoin/bips/pull/29) shows a Python= and a NodeJS way to input that test vector password as intended.

Some input devices may already handle the input as NFC,= which is great, but per the BIP38 proposal, that shouldn't be assumed,= so various implementations are cross-compatible. If one implementation ass= umes the input is already NFC, they may encode/decode the password incorrec= tly, and lock a user out of their wallet. Android allows different user key= boards to be used, so I'm guessing there's one somewhere that allow= s manual entry of unicode codepoints that could be used to enter a null cha= racter, and with the next version of iOS, Apple devices will also get custo= m keyboard options, too, so even if the default Apple keyboard does NFC-for= m properly, other developers' keyboards may not. So while it is an extr= eme edge case, that is not very likely to be used as a "real password&= quot; by any user, that's what test vectors are for: to test for the ed= ge case that you might not have expected and handled in your implementation= .

Brooks


On Tue, Jul 15, 2014 at 8:07 AM, Eric Winer <enwiner@gmai= l.com> wrote:
I don't know for sure if the tes= t vector is correct NFC form. =C2=A0But for what it's worth, the Pile o= f Poo character is pretty easily accessible on the iPhone and Android keybo= ards, and in this string it's already in NFC form (f09f92a9 in the test= result). =C2=A0I've certainly seen it in usernames around the internet= , and wouldn't be surprised to see it in passphrases entered on smartph= ones, especially if the author of a BIP38-compatible app includes a (possib= ly ill-advised) suggestion to have your passphrase "include special ch= aracters".

I haven't seen the NULL character on any smar= tphone 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. =C2=A0It seems unlikely that NULL would be in a real-wo= rld passphrase entered by a sane user.


On Tue,= Jul 15, 2014 at 8:03 AM, Mike Hearn <mike@plan99.net> wrote:<= br>
[+cc aaron]

We recently added an implem= entation of BIP 38 (password protected private keys) to bitcoinj. It came t= o my attention that the third test vector may be broken. It gives a hex ver= sion 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 thin= k any sane user would put into a passphrase, I question the value of this t= est vector. NFC form is intended to collapse things like umlaut control cha= racters onto their prior code point, but here we're feeding the algorit= hm what is basically garbage so I'm not totally surprised that differen= t 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 t= o verify NFC normalisation I suggest using a different, more realistic test= string, like Z=C3=BCrich, or something written in Thai.



Test 3:
  • Passphrase =CF=92=CC=81=E2=90=80=F0=90=90=80=F0=9F=92=A9 (\u03D2= \u0301\u0000\U00010400\U0001F4A9;=C2=A0GREEK UPSILON WITH HOOK,=C2=A0COMBINING ACUTE ACCENT,= =C2=A0NULL,= =C2=A0DESERET = CAPITAL LETTER LONG I,=C2=A0PILE OF POO)
  • Encrypted key: 6PRW5o9FLp4gJDDVqJQKJFTpMvdsSGJxMYHtHaQBF3ooa8mwD69bapcD= Qn
  • Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF
  • Unen= crypted private key (WIF): 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTM= SZ4
  • Note:=C2=A0The non-standard UTF-8 characters in this passphrase = should be NFC normalized to result in a passphrase of0xcf9300f090908= 0f09f92a9=C2=A0before further processing


<= /div>

-----------------------------------------------------------------------= -------
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/b= ds
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment



-----------------------------------------------------------------------= -------
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/b= ds
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a11c2ab5c884c4204fe3cda91--