Jonas Schnelli [ARCHIVE] on Nostr: 📅 Original date posted:2016-07-26 📝 Original message:Hi > ==Generating the ...
📅 Original date posted:2016-07-26
📝 Original message: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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160726/d070c20b/attachment.sig>;
📝 Original message: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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160726/d070c20b/attachment.sig>;