public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Winer <enwiner@gmail.com>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] BIP 38 NFC normalisation issue
Date: Tue, 15 Jul 2014 09:07:47 -0400	[thread overview]
Message-ID: <CAObn+gfbH61kyv_ttT4vsQuNFRWLB5H3xaux7GQ0co82ucO_eA@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3ZzCBohXWZmZxE=ofP74Df4Hd-hCLH6jYn=JKbiqNQXA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3543 bytes --]

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 <http://codepoints.net/U+03D2>, COMBINING ACUTE
>    ACCENT <http://codepoints.net/U+0301>, NULL
>    <http://codepoints.net/U+0000>, DESERET CAPITAL LETTER LONG I
>    <http://codepoints.net/U+10400>, PILE OF POO
>    <http://codepoints.net/U+1F4A9>)
>    - 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
>
>

[-- Attachment #2: Type: text/html, Size: 6035 bytes --]

  reply	other threads:[~2014-07-15 13:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-15 12:03 [Bitcoin-development] BIP 38 NFC normalisation issue Mike Hearn
2014-07-15 13:07 ` Eric Winer [this message]
2014-07-15 13:19   ` Andreas Schildbach
2014-07-15 13:32     ` Michael Wozniak
2014-07-15 15:13   ` Brooks Boyd
2014-07-15 18:20     ` Mike Hearn
2014-07-15 22:23       ` Aaron Voisine
2014-07-16  9:12         ` Mike Hearn
2014-07-16  9:17         ` Andreas Schildbach
2014-07-16  9:29           ` Mike Hearn
2014-07-16 10:46             ` Andreas Schildbach
2014-07-16 11:04               ` Andreas Schildbach
2014-07-16 21:06                 ` Aaron Voisine
2014-07-16 22:02                   ` Andreas Schildbach
2014-07-16 22:22                     ` Andreas Schildbach
2014-07-17 10:59                     ` Mike Hearn
2014-07-17 11:27                       ` Andreas Schildbach
2014-07-16 12:38             ` Wladimir
2014-07-15 15:17   ` Jeff Garzik
2014-07-15 15:20     ` Mike Hearn
2014-07-15 15:32     ` Andreas Schildbach
2014-07-15 15:53       ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAObn+gfbH61kyv_ttT4vsQuNFRWLB5H3xaux7GQ0co82ucO_eA@mail.gmail.com \
    --to=enwiner@gmail.com \
    --cc=andreas@schildbach.de \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox