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 --]
next prev parent 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