From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AFF0594D for ; Tue, 26 Jul 2016 20:10:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from server3 (server3.include7.ch [144.76.194.38]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id E23DE178 for ; Tue, 26 Jul 2016 20:10:20 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id 9C9C22E6055A; Tue, 26 Jul 2016 22:10:19 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1 autolearn=ham version=3.3.1 Received: from Jonass-MacBook-Pro-2.local (cable-static-140-182.teleport.ch [87.102.140.182]) by server3 (Postfix) with ESMTPSA id EE0362D0016A for ; Tue, 26 Jul 2016 22:10:18 +0200 (CEST) To: bitcoin-dev@lists.linuxfoundation.org References: <5797AC88.8030507@gmail.com> From: Jonas Schnelli Message-ID: <5797C3A7.5030600@jonasschnelli.ch> Date: Tue, 26 Jul 2016 22:10:15 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5797AC88.8030507@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4qRP8NVuxpCvtAh08CQwvFo6SM7gg44Af" Subject: Re: [bitcoin-dev] BIP proposal: derived mnemonics X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 20:10:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4qRP8NVuxpCvtAh08CQwvFo6SM7gg44Af Content-Type: multipart/mixed; boundary="VJx06OMXCuBdxIF5jH7jx5SHv6sBD5lQx" From: Jonas Schnelli To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <5797C3A7.5030600@jonasschnelli.ch> Subject: Re: [bitcoin-dev] BIP proposal: derived mnemonics References: <5797AC88.8030507@gmail.com> In-Reply-To: <5797AC88.8030507@gmail.com> --VJx06OMXCuBdxIF5jH7jx5SHv6sBD5lQx Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi > =3D=3DGenerating the master mnemonic=3D=3D >=20 > The master mnemonic is first derived as a standard mnemonic as describe= d > in BIP39. > =3D=3DFrom master mnemonic to derived mnemonics=3D=3D >=20 > From the master mnemonic a new string is created: >=20 > string =3D MasterMnemonic + " " + Count + " " + Strength; >=20 > Here, MasterMnemonic are the space separated words of the master > mnemonic. Count =3D 0, 1, 2 denotes the different derived mnemonics of = a > given strength and Strength =3D numWords / 3 * 32, where numWords is th= e > number of words desired for the derived mnemonic and only integer > arithmetic is used in the calculation (e.g. for numWords =3D 14, Streng= th > =3D 128). Both Count and Strength are converted to strings. >=20 > This string is then hashed using sha512: >=20 > hash =3D 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. --VJx06OMXCuBdxIF5jH7jx5SHv6sBD5lQx-- --4qRP8NVuxpCvtAh08CQwvFo6SM7gg44Af Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXl8OnAAoJECnUvLZBb1PsjP8QAJNodr+vRg82vAR48OhUKhnl 1FT98NdcRjxonIAh+YKPG8BM4n+QD+U+KUpRngKgxlA9bNC6b/zmiVxfCJlViTo+ uxDqAFyRrjD40/nn9mnuKkZpOZ1yyYpMjpxzJbkZrIXiOh8kD+XNffiEI50HwC0z 8cuNBmTIaVRD5SCyg9is5vWsZhgGYgPBhiaVueFxIFgbySpFeNvzpha81ZQOfJ4i Q0M2QPAxDYs+R1oM9maFwX3QV1gBtPmJiwiDQF6jMH8KOjJOxxXYZqTBHvTeiC0g YhuKc9sSRfc1BwVuLvRCBYueKU7mG3mPX8LR8eyXFj+cvbhFx4atd26bHR14kOUe LqMHszl4X9nJDXxIt/P8lMqE8M/dAxeJj8F/Qw4DaSdjDMEtu4CNB+WwyNdGVfqU 3EcFFZo0Ra82XkJSWZ4HixwdtqHAHLJm1wemLCAiVyZJh+VCtloMYSvc1Z2J8wW6 utFj+kmanYz2enCihQwkVznsTLTFtifdTwJqeB+DAdOPWQE4rAcq4tfgN4qnrjn+ KjrSJemNUSZRrbMj3h2tQ/mD87AQhORcEnubz+YxCXtPPIowC2eCr3OTVTq1PyGD LW510zCd1rURLmpvHcGN/eCXMrvfo+X4AhX4UvwHYrjvJyDiifCtPD+m43+KlIzi lPVs6JI/99MpS3HeFRVA =sLpE -----END PGP SIGNATURE----- --4qRP8NVuxpCvtAh08CQwvFo6SM7gg44Af--