diff options
author | Adam Back <adam.back@gmail.com> | 2020-03-25 14:54:18 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2020-03-25 13:54:35 +0000 |
commit | aacc3d962c6a398f514f5a952389e5a8b5b4fe5d (patch) | |
tree | fbd7c778d7afb0a03a1574a8ea02017443c72d44 | |
parent | 50b732cb41bfd91fa1cecef647f2c22dc82b7ced (diff) | |
download | pi-bitcoindev-aacc3d962c6a398f514f5a952389e5a8b5b4fe5d.tar.gz pi-bitcoindev-aacc3d962c6a398f514f5a952389e5a8b5b4fe5d.zip |
Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains
-rw-r--r-- | 8d/bad709ae212bb12098e12b2f263ddf3e95fc0c | 399 |
1 files changed, 399 insertions, 0 deletions
diff --git a/8d/bad709ae212bb12098e12b2f263ddf3e95fc0c b/8d/bad709ae212bb12098e12b2f263ddf3e95fc0c new file mode 100644 index 000000000..df0cd34ed --- /dev/null +++ b/8d/bad709ae212bb12098e12b2f263ddf3e95fc0c @@ -0,0 +1,399 @@ +Return-Path: <adam.back@gmail.com> +Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id F399EC0177 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 25 Mar 2020 13:54:35 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by whitealder.osuosl.org (Postfix) with ESMTP id E296B86BA4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 25 Mar 2020 13:54:35 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from whitealder.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id Yt+StbSqRpWN + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 25 Mar 2020 13:54:34 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com + [209.85.208.180]) + by whitealder.osuosl.org (Postfix) with ESMTPS id 0B82A86B90 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 25 Mar 2020 13:54:34 +0000 (UTC) +Received: by mail-lj1-f180.google.com with SMTP id w1so2532754ljh.5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 25 Mar 2020 06:54:33 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:references:in-reply-to:reply-to:from:date:message-id + :subject:to:cc:content-transfer-encoding; + bh=pK/VHS0dDhe9ykaKcHJ0mFNZIWAMuSsMf165DL7MNX0=; + b=UTczVHqywLLxp2gzShjwnccvOyKm4g2xgvF06PEoaBt48q4vvFHOShuuuVuf6D4ZQg + TlcVdmpA69mI8t73Yk/KWr/f2nHUWiQFb4kjPBqo0Zwj41xzXxA0mgGUGsloYMPnvpiA + 8+TKRv9tZe6JIJhg5RCrWXinpwRYJVH7Ei6YYcW9AIoMnielQ/SMzzBNXxZMqjGUsep0 + /9jLJIWXzN/0fWQlWtZncfok9FRlSEx+hGT/5WuEgdmQK2wMrivGEhUGMgshQwTOVN8G + eQdF7kvAsMEh/hB3AWm0YrpiZ/rpmF913mIPZOAB+cHHb1RGH3vLNY8ynBQ/By4JycJ3 + JG/Q== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:reply-to + :from:date:message-id:subject:to:cc:content-transfer-encoding; + bh=pK/VHS0dDhe9ykaKcHJ0mFNZIWAMuSsMf165DL7MNX0=; + b=pEaAK+5OioIidpffIFG26lT+5QTMwttzNntaoSp2TIxaJNgY458M6Ob5S1HxWZiwRk + gFsrGe1cf7iiDAk5x3TCuORcM16on9tUjmucqBnjeeoIJN2hZPIP4VKgKBW99uUnDG5+ + gFvg1ONJzJBLqljDB3pRHUAa+97zva0Kg0QJh2M/h0ID9XyvIhPo7LVO29mfyi1tCqR2 + Tfc9vdTF39AWL7p4BR2wvYn752t474mpyrPFLeNGlcSPKd/8q9R4C6JBYE+GswKXRMmF + WFy/5Gg3wuS53DXV7HdfwNjSoR4f8s7quD4QU3mylZ6W2kP3iSYNY//UsvuSzqypovyt + 5CfA== +X-Gm-Message-State: AGi0PuYsXSa0ra/X7NmHEyT7bXik/UbbZ9qhKRcgQ2y/pC3EH9+kicpi + aAv14HUk15GxtVh0kQbKY+XWcb5vZD/QOhr2Qmo= +X-Google-Smtp-Source: APiQypI1q0zHPthRKTUJvdBUtWCsmztWzjHbNwA6ed8bdvbiCv7EwWlnyz2YWhjKOjW06UnduRyJpnZD5YtEulN9J+I= +X-Received: by 2002:a2e:b0c2:: with SMTP id g2mr2140324ljl.102.1585144471841; + Wed, 25 Mar 2020 06:54:31 -0700 (PDT) +MIME-Version: 1.0 +References: <_CC9MLKCy5rmooAmR91_34tQxgDiXDJCdY4W6_X6xqDJUiAEuaWBVi8iBaFipx2KGt5_mf5XqFKMfoNgemTPCMgraWt5CVRifUM5iMolxto=@protonmail.com> + <S90SB9DcluBjzhnWrbT1Urh61XgVcn6ynEU7EGsfR-UhGGMxPOXMuJdwM0BPtdAcIaL22B4zR0Pooe4Yaoi0zBPFnnwQ4WSSpL7FoW4OOBA=@protonmail.com> + <c7b9bd243e7ae6a5a4e55f4b18d7d656c3690380.camel@timruffing.de> +In-Reply-To: <c7b9bd243e7ae6a5a4e55f4b18d7d656c3690380.camel@timruffing.de> +Reply-To: adam@cypherspace.org +From: Adam Back <adam.back@gmail.com> +Date: Wed, 25 Mar 2020 14:54:18 +0100 +Message-ID: <CALqxMTH4+WWKDzLh-6gC5GcaHvSMJjY9S8HNy-DwNgefdpuyUA@mail.gmail.com> +To: Tim Ruffing <crypto@timruffing.de>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable +Subject: Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 25 Mar 2020 13:54:36 -0000 + +I think the point is to use this proposed extension/standard for a +kind of "seed management" function, set it up on an offline device (an +always offline laptop, or a modified hardware wallet) where you put +the master seed. And then you use this as a kind of seed manager and +transcript the seeds for different sub-wallets into the respective +wallets as BIP39 mnemonics. + +So I do not think it needs any changes from existing wallet authors, +as the interaction point is a bip 39 seed, which they mostly know how +to use. Indeed if you were to modify an existing wallet to accept the +master seed from seed management scheme and derive the seed it needs +on each wallet, then that would create a weakest link in the chain +risk - if that wallet was insecure, or compromised then all other +derived seeds would be also and you want independence for each wallet. + +I do think that this use case is a practical problem for people +managing multiple seeds for various wallets in a bitcoin business +setting or even power users - you lose the single backup design, +because it's too cumbersome to create fresh backups for each of +multiple wallets, especially distributed , fireproof cryptosteel etc +backups and so in practice for multi wallet scenarios probably they +are not all full backed up or not backed up as robustly (not as +geo-redundant, fireproof, secret-shared etc). + +Adam + +On Tue, 24 Mar 2020 at 09:32, Tim Ruffing via bitcoin-dev +<bitcoin-dev@lists.linuxfoundation.org> wrote: +> +> I think your proposal is simply to use BIP32 for all derivations and +> the observation that you can work with derived keys with the +> corresponding suffixes of the path. I believe that this is a good idea. +> +> But I don't think that simply writing a standard will help. It's just +> one step. If all your wallets support incompatible formats, we should +> work on fixing this because that's the root of the issue. Otherwise you +> end up converting keys back and forth manually (as Chris pointed out), +> and this can't be the goal. +> +> But then you need to reach out to wallet devs explicitly and get them +> involved in creating the standard. Otherwise they won't use it. That's +> a hard process, and it's even harder to make sure that the resulting +> proposal isn't way too complex because everyone brings their special +> case to the table. +> +> Tim +> +> On Sun, 2020-03-22 at 11:58 +0000, Ethan Kosakovsky via bitcoin-dev +> wrote: +> > I have completely revised the wording of this proposal I hope to be +> > clearer in explaining the motivation and methodology. +> > +> > https://gist.github.com/ethankosakovsky/268c52f018b94bea29a6e809381c05d= +6 +> > +> > Ethan +> > +> > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origina= +l Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 +> > On Friday, March 20, 2020 4:44 PM, Ethan Kosakovsky via bitcoin-dev < +> > bitcoin-dev@lists.linuxfoundation.org> wrote: +> > +> > > I would like to present a proposal for discussion and peer review. +> > > It aims to solve the problem of "too many seeds and too many +> > > backups" due to the many reasons stipulated in the proposal text. +> > > +> > > https://gist.githubusercontent.com/ethankosakovsky/f7d148f588d14e0bb4= +f70bb6afc509d0/raw/6da51e837b0e1f1b2b21f3d4cbc2c5a87969ffd5/bip-entropy-fro= +m-bip32.mediawiki +> > > +> > > <pre> +> > > BIP: +> > > Title: Deterministic Entropy From BIP32 Keychains +> > > Author: Ethan Kosakovsky ethankosakovsky@protonmail.com +> > > Comments-Summary: No comments yet. +> > > Comments-URI: +> > > Status: Proposed +> > > Type: Standards Track +> > > Created: 2020-03-20 +> > > License: BSD-2-Clause +> > > OPL +> > > </pre> +> > > +> > > =3D=3DAbstract=3D=3D +> > > +> > > This proposal provides a way to derive entropy from a HD keychain +> > > path in order to deterministically derive the initial entropy used +> > > to create keychain mnemonics and seeds. +> > > +> > > =3D=3DMotivation=3D=3D +> > > +> > > BIP32 uses some initial entropy as a seed to deterministically +> > > derive a BIP32 root for hierarchical deterministic keychains. BIP39 +> > > introduced a method of encoding initial entropy into a mnemonic +> > > phrase which is used as input to a one way hash function in order +> > > to deterministically derive a BIP32 seed. The motivation behind +> > > mnemonic phrases was to make it easier for humans to backup and +> > > store offline. There are also other variations of this theme. +> > > +> > > The initial motivation of BIP32 was to make handling of large +> > > numbers of private keys easier to manage and backup, since you only +> > > need one BIP32 seed to cover all possible keys in the keychain. In +> > > practice however, due to various wallet implementations and +> > > security models, the average user may be faced with the need to +> > > handle an ever growing number of seeds/mnemonics. This is due to +> > > incompatible wallet standards, hardware wallets (HWW), seed formats +> > > and standards, as well as, the need to used a mix of hot and cold +> > > wallets depending on the application and environment. +> > > +> > > Examples would span wallets on mobile phones, online servers +> > > running protocols like Join Market or Lightning, and the difference +> > > between Electrum and BIP39 mnemonic seed formats. The reference +> > > implementation of Bitcoin Core uses BIP32, while other +> > > cryptocurrencies like Monero use different mnemonic encoding +> > > schemes. +> > > +> > > We must also consider the different variety of physical backups +> > > including paper, metal and other physical storage devices, as well +> > > as the potentially splitting backups across different geographical +> > > locations. This complexity may result in less care being taken with +> > > subsequently generated seeds for new wallets need to be stored and +> > > it ultimately results in less security. In reality, the idea of +> > > having "one seed for all" has proven to be more difficult in +> > > practice than originally thought. +> > > +> > > Since all these derivation schemes are deterministic based on some +> > > initial entropy, this proposal aims to solve the above problems by +> > > detailing a way to deterministically derive the initial entropy +> > > used for new root keychains using a single BIP32 style "master root +> > > key". This will allow one root key or mnemonic to derive any +> > > variety of different root keychains in whatever format is required +> > > (like BIP32 and BIP39 etc). +> > > +> > > =3D=3DSpecification=3D=3D +> > > +> > > Input starts with a BIP32 seed. Derivation scheme uses the format +> > > `m/83696968'/type'/index'` where `type` is the final seed type, and +> > > `index` in the key index of the hardened child private key. +> > > +> > > type +> > > +> > > bits +> > > +> > > output +> > > +> > > 0 +> > > +> > > 128 +> > > +> > > 12 word BIP39 mnemonic +> > > +> > > 1 +> > > +> > > 256 +> > > +> > > 24 word BIP39 mnemonic +> > > +> > > 2 +> > > +> > > 128 +> > > +> > > 12 word Electrum mnemonic +> > > +> > > 3 +> > > +> > > 256 +> > > +> > > 24 word Electrum mnemonic +> > > +> > > 4 +> > > +> > > 256 +> > > +> > > WIF for Bitcoin Core +> > > +> > > 5 +> > > +> > > 256 +> > > +> > > 25 word Monero mnemonic +> > > +> > > Entropy is calculated from the HMAC-SHA512(key=3Dk, msg=3D'bip-entrop= +y- +> > > from-bip32') of the derived 32 byte private key (k). Entropy is +> > > taken from the result according to the number of bits required. +> > > This entropy can then be used as input to derive a mnemonic, wallet +> > > etc according to the`type` specified. +> > > +> > > =3D=3DCompatibility=3D=3D +> > > +> > > In order to maintain the widest compatibility, the input to this +> > > function is a BIP32 seed, which may or may not have been derived +> > > from a BIP39 like mnemonic scheme. This maintains the original +> > > motivation that one backup can store any and all child derivation +> > > schemes depending on the user's preference or hardware signing +> > > devices. For example, devices that store the HD seed as a BIP39 +> > > mnemonic, Electrum seed, or BIP32 root key would all be able to +> > > implement this standard. +> > > +> > > =3D=3DDiscussion=3D=3D +> > > +> > > This proposal could be split into multiple discrete BIPs in the +> > > same way that BIP32 described the derivation mechanics, BIP39 the +> > > input encoding with mnemonics, and the derivation paths like BIP44, +> > > BIP49 and BIP84. This has been avoided to reduce complexity. The +> > > resulting private key processed with HMAC-SHA512 and truncated as +> > > necessary. HMAC-SHA512 was chosen because it may have better +> > > compatibility in embedded devices as it's already required in +> > > devices supporting BIP32. +> > > +> > > =3D=3DTest Vectors=3D=3D +> > > +> > > =3D=3D=3DTest case 1=3D=3D=3D +> > > +> > > MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind +> > > employ giant era attitude exit final oval one finger decorate pair +> > > useless super method float toddler dance +> > > MASTER BIP32 ROOT KEY: +> > > xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfG +> > > JNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp +> > > PATH: m/83696968'/0'/0' +> > > BITS REQUIRED: 128 +> > > +> > > DERIVED CHILD +> > > WIF=3DL3cefeCHyo8jczVjckMxaiPBaPUunc3D8CsjRxYbYp3FhasGpsV3 +> > > DERIVED CHILD +> > > k=3Dbed343b04ba0216d9eeebff0366b61c4179d90d44b61c716ef6d568836ba4d23 +> > > CHILD ENTROPY=3D6458698fae3578b48a64124ea3514e12 +> > > CONVERT ENTROPY TO +> > > WIF=3DKwDiBf89QgGbjEhKnhXJuH7T2Vv72UKQA8KRkmNwVFS2znAS5xb9 +> > > CHILD BIP39 MNEMONIC=3Dgold select glue fragile fiscal fog civil +> > > liquid exchange box fatal caught +> > > CHILD BIP39 +> > > SEED=3D2a2720e5590d4ec3140e51ba1b0b0a5183222c1668977c8a57572b0ea55d23 +> > > 8cd8e899b3b1870e48894ca837e41e5d0db07554715efb21556fdde27f9f7ba153 +> > > CHILD BIP32 ROOT +> > > KEY=3Dxprv9s21ZrQH143K2ZH5qacptquLGvcYpHSNeyFVCU8Ur4u9kocajbBgcaCbHkG +> > > bwDsBR661H29F54j5mz14kwXbY9PZKdNRdjgRcGfshBK9XXb +> > > +> > > =3D=3D=3DTest case 2=3D=3D=3D +> > > +> > > MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind +> > > employ giant era attitude exit final oval one finger decorate pair +> > > useless super method float toddler dance +> > > MASTER BIP32 ROOT KEY: +> > > xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfG +> > > JNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp +> > > PATH: m/83696968'/1'/0' +> > > BITS REQUIRED: 256 +> > > +> > > DERIVED CHILD +> > > WIF=3DL1zCbtnDWUN4vJA3De4sxmJnoRim57CQUuBb4KBoRNs2EMEq2Brg +> > > DERIVED CHILD +> > > k=3D8e3ca6054a6303f4a6a1bcbda6134c9802f4f0a0d76b0ee6b69b06b1e80b2192 +> > > CHILD +> > > ENTROPY=3Dec4e2f7e2c3fca9a34fa29747bf8ba0ab7f05136f37e134e2457e9e5363 +> > > 9670b +> > > CONVERT ENTROPY TO +> > > WIF=3DL594JSCygt2wBaB9mCpXjiLkkxkEojpBdNXG8UrrdLd2LvPBRMUs +> > > CHILD BIP39 MNEMONIC=3Dunable imitate test flash witness escape +> > > stadium early inner thank company betray lecture chuckle swift hurt +> > > battle illness bicycle stable fat bronze order high +> > > CHILD BIP39 +> > > SEED=3D73509b0e847ee66bddeb098a55063d73e8c6dd5f1c1db6969c668bb54c19bd +> > > e6eae8acc29a81118d1d9719fa1bc620fee7edd7c15a17bcaf70b0fdfc0c0c3803 +> > > CHILD BIP32 ROOT +> > > KEY=3Dxprv9s21ZrQH143K4PfLyyjYLVmKbnUTNFK6Y7jPKWfRZB3iSw1Gy9qowEzkYHf +> > > etVabfmjHEEPrcTJbh7chae33Sm9uAjuXzhSL6Li8dcwM9Bm +> > > +> > > =3D=3D=3DTest case 3=3D=3D=3D +> > > +> > > MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind +> > > employ giant era attitude exit final oval one finger decorate pair +> > > useless super method float toddler dance +> > > MASTER BIP32 ROOT KEY: +> > > xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfG +> > > JNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp +> > > PATH: m/83696968'/4'/0' +> > > BITS REQUIRED: 256 +> > > +> > > DERIVED CHILD +> > > WIF=3DKwdD5PYnCU3xQDfFJ6XBf6UDaLrTUxrKmBpdjRuuavWyqAQtpaA2 +> > > DERIVED CHILD +> > > k=3D0c169ce2c17bea08512a7519769e365242a1562bd63c4c903daef516000efbf2 +> > > CHILD +> > > ENTROPY=3D25573247f8a76799f7abc086b9286b5a7ccb03cb8d3550f48ac1e71d908 +> > > 32974 +> > > CONVERT ENTROPY TO +> > > WIF=3DKxUJ8VzMk7uWDEcwYjLRzRMGE6sSpwCfQxkE9GEwAvXhFSDNba9G +> > > CHILD BIP39 MNEMONIC=3Dcensus ridge music vanish island smooth team +> > > job mammal sing bracket reject smile limit comfort pluck extend +> > > picture race soda suit dose place obtain +> > > CHILD BIP39 +> > > SEED=3D4e5c82be6455ecf0884d9475435e29a9afb9acf70b07296d7e5039c866e4d5 +> > > 4647706918b9d14909dfbd7071a4b7aee8a4ad0ac2bf48f0a09a8899dd28564418 +> > > CHILD BIP32 ROOT +> > > KEY=3Dxprv9s21ZrQH143K2kekJsK9V6t4ZKwHkY1Q3umxuaAhdZKGxCMpHiddLdYUQBo +> > > ynszpwnk5upoC788LiT5MZ5q1vUABXG7AMyZK5UjD9iyL7Am +> > > +> > > =3D=3DReferences=3D=3D +> > > +> > > BIP32, BIP39 +> > > +> > > =3D=3DCopyright=3D=3D +> > > +> > > This BIP is dual-licensed under the Open Publication License and +> > > BSD 2-clause license. +> > > +> > > bitcoin-dev mailing list +> > > bitcoin-dev@lists.linuxfoundation.org +> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> > +> > _______________________________________________ +> > bitcoin-dev mailing list +> > bitcoin-dev@lists.linuxfoundation.org +> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + |