From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 196CAC07FF for ; Sat, 21 Mar 2020 01:46:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 120F3876C7 for ; Sat, 21 Mar 2020 01:46:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ts_wduIgcZff for ; Sat, 21 Mar 2020 01:46:57 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ua1-f67.google.com (mail-ua1-f67.google.com [209.85.222.67]) by fraxinus.osuosl.org (Postfix) with ESMTPS id B3A23876C3 for ; Sat, 21 Mar 2020 01:46:57 +0000 (UTC) Received: by mail-ua1-f67.google.com with SMTP id r47so2942082uad.11 for ; Fri, 20 Mar 2020 18:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lifewithalacrity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XvJ9pwoqJb7Y1v2vMP4qHrRlBtlqbD1FRE+xHrHDwuA=; b=kL8Bb9JmVpLQ2+OwLMHnoIe9BVanZ2qtUCaha6JRwyndFthY4BzLca+KQJD2joHgs+ PE3PgKFvQlWg/k0QY77jfrQCgN1aA62/lazW29J2MP5bHLtp06FdxpM++kTM1AlTVf+j wnosuaj3VYCCFyNiiRYMqJd2esqP3SUYbRTEAnnVdC4lv22Jq7+hMwXNAjPgENaDqlde i+Op2texMiMZ5LOPE96yyxYriBWldP9WIE206Ydx5ESAp3dOzCJun2RY2rTxiFXZkthT Tq64BYzbjFokGzTH4svnkIpjEiy1d18RQz+Ndd0Ga9koOKvrK6+iERJQlHxIYCnYitB3 qBwA== 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:from:date :message-id:subject:to:cc; bh=XvJ9pwoqJb7Y1v2vMP4qHrRlBtlqbD1FRE+xHrHDwuA=; b=FauxkjFCovG9RkO+8rSq7Gp9ezsHUnSzYaQeHe6Xf0iFm30FDa8SwZPBRPKtFfkGr/ 0wGA9X0FPr4205aaiL8U53ldjuMudl6QGSCJJ6DECZ3C9L1a7AS06+zVkozG+3BE19D3 Xi7abtgmhzZj7T8Lkk2Rmb8ittIEdrEIRwgoWdZMYxXBAvx2CsFN1BXw2SWZ9OTZS1Ad W8QHvqtAer9j+gg32chcSPUcrnX4SYFJ1rX7sqGt+oBIRIeciCtJs8J1ORHekAD+GzD0 Pv08dHIuXD6RdqCQJVOMs6wdVLilW/zmi83qJgDDJVVQahqipzgJzydqqaAtC0qUeGkN Cu6g== X-Gm-Message-State: ANhLgQ3P5YCrxjEhCnsYjdolZT7Apg/zD6e8gRVnq1Rxoi1I72wMYA1b TiUetN/Mim7aJAnbBlc9jR4RI0HcZz+D77Ye1kk0L+iJ6hE= X-Google-Smtp-Source: ADFU+vuHZKByDkZ8xT9mu7GS3MHAtUujGVEXRLCtukzQ5KB4pwEHA5DqU36jN9DoO7aOsxzrWH/OC0XKrQOFfKTBHzs= X-Received: by 2002:a9f:3b02:: with SMTP id i2mr7471760uah.33.1584755216214; Fri, 20 Mar 2020 18:46:56 -0700 (PDT) MIME-Version: 1.0 References: <_CC9MLKCy5rmooAmR91_34tQxgDiXDJCdY4W6_X6xqDJUiAEuaWBVi8iBaFipx2KGt5_mf5XqFKMfoNgemTPCMgraWt5CVRifUM5iMolxto=@protonmail.com> <20200320200253.GC13916@coinkite.com> In-Reply-To: <20200320200253.GC13916@coinkite.com> From: Christopher Allen Date: Fri, 20 Mar 2020 18:46:19 -0700 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000b7f08d05a1539317" X-Mailman-Approved-At: Sat, 21 Mar 2020 01:53:13 +0000 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 01:46:59 -0000 --000000000000b7f08d05a1539317 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with the problem statement in this proposal, but not the proposed solution. The challenge of safely securing a seed for a single signature is not insignificant. Blockchain Commons has published procedures that we consider the current best practices for cold storage in a free book at http://bit.ly/SmartCustodyBookV101 and in github at https://github.com/BlockchainCommons/smartcustodybook. It currently requires a couple of hours and $200 or more of materials (home safe, 2 ledgers, titanium blanks, etc.) to safely product (significantly less time and money than Glacier Protocol). Presumably, people are not going to go to this level of protection for too many keys, thus there needs to be methods to leverage the root seeds that are properly protected. Currently Blockchain Commons is working on standards for airgap solutions for storing and signing from offline keys. Scenarios include using Shamir and SLIP-39 on an offline device with no-WiFi or Bluetooth, an air-gapped mobile phone in airplane mode, or another dedicated device (for instance the SafeKey device if open source was an option). You would use this device to create and restore seeds, convert seeds from BIP-39 to SLIP-39, derive HD keys, and then use QR code from the device to transfer the generated child keys for use by different apps. In some cases, this offline device could also read QR transactions and sign them. We have working prototypes of this today. This technique works fine for online Bitcoin apps that accept child keys in the form of xprv (or equivalents) such as those our FullyNoded2 iOS wallet supports, but the problem for other wallets is that you can't go from an xprv back to a seed =E2=80=94 the xprv creation is a one-way hmac-sha512 op= eration (still not convinced this was a good decision). What I think Ethan is proposing is the ability to turn any child derived xprv key into a new set valid seed words that could be used by a wallet or other devices that don't understand xprv and will only allow import of new seeds words. This gets even more complicated if the seed words are not the standard BIP-39 set (which BTW, are not an ideal set of words, the selection of the SLIP-39 words is much better). Though possibly pragmatic, this approach would be a hack =E2=80=93 starting= with some raw entropy, convert this to an entropy seed, then to words, then hmac to xprv, then derive child keys, then convert that child key to a new entropy seed, then hmac to xprv, and then derive child keys again, etc. I'd really prefer to start with finding standards ways to protect the entropy seed (not specifically the bip39 words derived from that but also as derived roots for WebAuthN/FIDO, GPG, Signal/Session, etc.) that can be then be used to create other hierarchies of keys using airgap solutions. For instance, here is what FullyNoded 2 currently uses to restore a Bitcoin wallet including root seed: { "birthdate": 1584725088, "label": "Testnet Single Signature", "entropy": "b3b17e8f425bf7b96d68b67867cdc816", "walletName": "DEFAULT_EBaiuGgZQS_StandUp", "descriptor": "wpkh([6955c2cb/84'/1'/0']tprv8giCxdrRRrKfQkXTJ4q2PNZBsPL7HiTXXteajiG8wqAGp= LVsHJfN1EwwKM8F8x1Cuk8p6vh1KrKBCuZtZdDtL6Sc2CB1ou8sYiGSf6hcujv/0/*)", "blockheight": 1 } Alternatively, FullyNoded 2 can also restore a wallets without the full seed, so for instance, if this QR restore was missing the entropy field, only derived child xprv from the descriptor could be used, so no other accounts could be created but new addresses as children of the xprv could be created. The advantage of of an entropy seed storage centered technique is that I can convert that entropy seed into either BIP39 words, or any number of SLIP-39 shards, or Lightning words, and back. We are also looking at using this with the VSS that underlies Schnorr Musig. We can talk other secure tool makers on how to use this raw entropy for other purposes to create chains or hierarchies of keys for their unique needs. Blockchain Common's doesn't have a full architecture for this yet as we are working on our POC and are seeking suggestions from other wallet vendors (in particular lightning and non-bitcoin secure services) on requirements. Let me know if you'd like to participate in the discussions (currently either Github issues or a Signal group for the group) =E2=80=94 Christopher Allen --000000000000b7f08d05a1539317 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with the problem statement in this proposal, but n= ot the proposed solution.

The challenge of safely securi= ng a seed for a single signature is not insignificant. Blockchain Commons h= as published procedures that we consider the current best practices for col= d storage in a free book at=C2=A0http://bit.ly/SmartCustodyBookV101 and in github at=C2=A0https://github.c= om/BlockchainCommons/smartcustodybook. It currently requires a couple o= f hours and $200 or more of materials (home safe, 2 ledgers, titanium blank= s, etc.) to safely product (significantly less time and money than Glacier = Protocol).=C2=A0

Presumably, people are not going = to go to this level of protection for too many keys, thus there needs to be= methods to leverage the root seeds that are properly protected.
=
Currently Blockchain Commons is working on standards for air= gap solutions for storing and signing from offline keys. Scenarios include = using Shamir and SLIP-39=C2=A0 on an offline device with no-WiFi or Bluetoo= th, an air-gapped mobile phone in airplane mode, or another dedicated devic= e (for instance the SafeKey device if open source was an option). You would= use this device to create and restore seeds, convert seeds from BIP-39 to = SLIP-39, derive HD keys, and then use QR code from the device to transfer t= he generated child keys for use by different apps. In some cases, this offl= ine device could also read QR transactions and sign them. We have working p= rototypes of this today.

This technique works fine= for online Bitcoin apps that accept child keys in the form of xprv (or equ= ivalents) such as those our FullyNoded2 iOS wallet supports, but the proble= m for other wallets is that you can't go from an xprv back to a seed = =E2=80=94 the xprv creation is a one-way hmac-sha512 operation (still not c= onvinced this was a good decision).=C2=A0

What I t= hink Ethan is proposing is the ability to turn any child derived xprv key i= nto a new set valid seed words that could be used by a wallet or other devi= ces that don't understand xprv and will only allow import of new seeds = words. This gets even more complicated if the seed words are not the standa= rd BIP-39 set (which BTW, are not an ideal set of words, the selection of t= he SLIP-39 words is much better).=C2=A0

Though pos= sibly pragmatic, this approach would be a hack =E2=80=93 starting with some= raw entropy, convert this to an entropy seed, then to words, then hmac to = xprv, then derive child keys, then convert that child key to a new entropy = seed, then hmac to xprv, and then derive child keys again, etc.
<= br>
I'd really prefer to start with finding standards ways to= protect the entropy seed (not specifically the bip39 words derived from th= at but also as derived roots for WebAuthN/FIDO, GPG, Signal/Session, etc.) = that can be then be used to create other hierarchies of keys using airgap s= olutions.

For instance, here is what FullyNoded 2 = currently uses to restore a Bitcoin wallet including root seed:
<= br>
{
=C2=A0 "birthdate": 1584725088,
=C2=A0 &quo= t;label": "Testnet Single Signature",
=C2=A0 "entrop= y": "b3b17e8f425bf7b96d68b67867cdc816",
=C2=A0 "wall= etName": "DEFAULT_EBaiuGgZQS_StandUp",
=C2=A0 "descr= iptor": "wpkh([6955c2cb/84'/1'/0']tprv8giCxdrRRrKfQkX= TJ4q2PNZBsPL7HiTXXteajiG8wqAGpLVsHJfN1EwwKM8F8x1Cuk8p6vh1KrKBCuZtZdDtL6Sc2C= B1ou8sYiGSf6hcujv/0/*)",
=C2=A0 "blockheight": 1
}
=

Alternatively, FullyNoded 2 can also restore a wa= llets without the full seed, so for instance, if this QR restore was missin= g the entropy field, only derived child xprv from the descriptor could be u= sed, so no other accounts could be created but new addresses as children of= the xprv could be created.

The advantage of of an= entropy seed storage centered technique is that I can convert that entropy= seed into either BIP39 words, or any number of SLIP-39 shards, or Lightnin= g words, and back. We are also looking at using this with the VSS that unde= rlies Schnorr Musig. We can talk other secure tool makers on how to use thi= s raw entropy for other purposes to create chains or hierarchies of keys fo= r their unique needs.

Blockchain Common's does= n't have a full architecture for this yet as we are working on our POC = and are seeking suggestions from other wallet vendors (in particular lightn= ing and non-bitcoin secure services) on requirements. Let me know if you= 9;d like to participate in the discussions (currently either Github issues = or a Signal group for the group)

=E2=80=94 Christo= pher Allen



--000000000000b7f08d05a1539317--