public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal: derived mnemonics
Date: Tue, 26 Jul 2016 22:10:15 +0200	[thread overview]
Message-ID: <5797C3A7.5030600@jonasschnelli.ch> (raw)
In-Reply-To: <5797AC88.8030507@gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1956 bytes --]

Hi


> ==Generating the master mnemonic==
> 
> The master mnemonic is first derived as a standard mnemonic as described
> in BIP39.



> ==From master mnemonic to derived mnemonics==
> 
> From the master mnemonic a new string is created:
> 
> string = MasterMnemonic + " " + Count + " " + Strength;
> 
> Here, MasterMnemonic are the space separated words of the master
> mnemonic. Count = 0, 1, 2 denotes the different derived mnemonics of a
> given strength and Strength = numWords / 3 * 32, where numWords is the
> number of words desired for the derived mnemonic and only integer
> arithmetic is used in the calculation (e.g. for numWords = 14, Strength
> = 128). Both Count and Strength are converted to strings.
> 
> This string is then hashed using sha512:
> 
> hash = sha512(string);

1)
My humble cryptographic understanding tells me that you should probably
use sha512_hmac where you add an passphrase and a salt.

2)
Side-note: Bip39 does still use PBKDF2 with 2048 iterations which I
personally consider "not enough" to protect a serious amount of funds.

Also the checksum based on the predetermined wordlist has some security
downsides over using a plain 32byte entropy (64hex chars) or a
base58check encoded extended private master key.

3)
Another idea:
What would speak against deriving a child key after bip32, lets say at
m/88'/0'/n' and use the derived 256bits to encode your mnemonic?
This would at least require your master mnemonic passphrase to derive a
valid "child mnemonic".

4)
I'm still not convinced if we should encourage users to "only store and
backup" the bip39 mnemonic.
Reconstructing funds from a seed can be difficult especially if you
don't have access to a trusted TX-indexed full node (~150GB of data
required).
Novice users might also underestimate the risk of losing metadata
coupled with their transactions when they only store the wallet seed.

</jonas>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-07-26 20:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-26 18:31 [bitcoin-dev] BIP proposal: derived mnemonics millibitcoin
2016-07-26 20:10 ` Jonas Schnelli [this message]
2016-07-27 10:39   ` Jochen Hoenicke
2016-07-27 10:53     ` Jonas Schnelli
2016-07-27 20:59     ` Gregory Maxwell

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=5797C3A7.5030600@jonasschnelli.ch \
    --to=dev@jonasschnelli.ch \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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