Delivery-date: Tue, 28 May 2024 15:29:33 -0700
Sender: bitcoindev@googlegroups.com
Date: Mon, 27 May 2024 19:04:50 -0700 (PDT)
From: Aneesh Karve <aneesh.karve@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <6d012560-4a66-4346-a1e8-8d8e5c879b29n@googlegroups.com>
Subject: [bitcoindev] Pre-BIP feedback: Secrets keychain with semantic derivation
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_161068_542952046.1716861890607"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_161068_542952046.1716861890607
Content-Type: multipart/alternative; 
	boundary="----=_Part_161069_700989787.1716861890607"

------=_Part_161069_700989787.1716861890607
Content-Type: text/plain; charset="UTF-8"

Greetings,

After reading and implementing BIP-85 <https://github.com/akarve/bipsea> I 
entertained the possibility of a generalized keychain application atop 
hierarchical deterministic wallets.

Here is the pre-proposal for said BIP-Keychain on GitHub 
<https://github.com/akarve/bip-keychain>. Below are the Abstract and 
Motivation. See the link above for the full spec.

Let me know if I should proceed to submit this as a proper BIP.

Thank you.


# Abstract

We extend the hierarchical deterministic wallet chain from BIP-32 with a new
application code for BIP-85 and a deterministic path derivation algorithm
that allows applications to create a large key-value map of secrets where 
the key
for each secret is a meaningful semantic path, as opposed to an arbitrary 
integer.
This secure key-value map can replace modern password managers and offers 
an improved, possibly trustless security profile.

# Motivation

BIP-85 specifies how to derive passwords, private keys, and entropy from 
paths
with the following form:

```
m/83696968'/{app_no}'/{index}'
```

Nevertheless BIP-85 has the following ambiguities and shortcomings:

1. Path construction is arbitrary in that there is no well-defined 
procedure to
extend the path for applications that require more than two parameters.
The implied convention is for paths to end with `{some_integer_n}'{index}'`
but there is no guidance on the order of parameters for applications that 
need more
than two inputs.

1. Return types for applications vary in interpretation and are
not specific enough to be actionable. For example sometimes `n` represents 
the
number of bytes, sometimes the number of characters, sometimes the number of
BIP-39 words, etc.

Moreover, modern password managers protect hot child secrets with a single 
root
master hot secret such that if the master secret is compromised all 
children are
also compromised.

BIP-Keychain proposes a new paradigm where numerous hot or cold secrets are 
derived
from hot but non-secret-compromising _derivation path keys_ that are in 
turn stored
under a hot master secret such that if this hot master is compromised only 
the
_derivation path keys_, and not the actual child secrets (_derivation path 
values_),
are compromised. Said hot master secret can itself be the child derivative 
of a
cold master key. The master key for deriving the secret values need not be 
stored
online nor with the derivation path keys and may be provided just-in-time 
by the
application.

Moreover, _generalized derivation paths_ may be interpreted not simply as an
input to key derivation but also as information about the real world. 

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/6d012560-4a66-4346-a1e8-8d8e5c879b29n%40googlegroups.com.

------=_Part_161069_700989787.1716861890607
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Greetings,<div><br /></div><div>After reading and <a href=3D"https://github=
.com/akarve/bipsea">implementing BIP-85</a> I entertained the possibility o=
f a generalized keychain application atop hierarchical deterministic wallet=
s.</div><div><br /></div><div>Here is the <a href=3D"https://github.com/aka=
rve/bip-keychain">pre-proposal for said BIP-Keychain on GitHub</a>. Below a=
re the Abstract and Motivation. See the link above for the full spec.</div>=
<div><br /></div><div>Let me know if I should proceed to submit this as a p=
roper BIP.</div><div><br /></div><div>Thank you.</div><div><br /></div><div=
><br /></div><div># Abstract<br /><br />We extend the hierarchical determin=
istic wallet chain from BIP-32 with a new<br />application code for BIP-85 =
and a deterministic path derivation algorithm<br />that allows applications=
 to create a large key-value map of secrets where the key<br />for each sec=
ret is a meaningful semantic path, as opposed to an arbitrary integer.<br /=
>This secure key-value map can replace modern password managers and offers =
an improved, possibly trustless security profile.<br /></div><div><br /></d=
iv><div># Motivation<br /><br />BIP-85 specifies how to derive passwords, p=
rivate keys, and entropy from paths<br />with the following form:<br /><br =
/>```<br />m/83696968'/{app_no}'/{index}'<br />```<br /><br />Nevertheless =
BIP-85 has the following ambiguities and shortcomings:<br /><br />1. Path c=
onstruction is arbitrary in that there is no well-defined procedure to<br /=
>extend the path for applications that require more than two parameters.<br=
 />The implied convention is for paths to end with `{some_integer_n}'{index=
}'`<br />but there is no guidance on the order of parameters for applicatio=
ns that need more<br />than two inputs.<br /><br />1. Return types for appl=
ications vary in interpretation and are<br />not specific enough to be acti=
onable. For example sometimes `n` represents the<br />number of bytes, some=
times the number of characters, sometimes the number of<br />BIP-39 words, =
etc.<br /><br />Moreover, modern password managers protect hot child secret=
s with a single root<br />master hot secret such that if the master secret =
is compromised all children are<br />also compromised.<br /><br />BIP-Keych=
ain proposes a new paradigm where numerous hot or cold secrets are derived<=
br />from hot but non-secret-compromising _derivation path keys_ that are i=
n turn stored<br />under a hot master secret such that if this hot master i=
s compromised only the<br />_derivation path keys_, and not the actual chil=
d secrets (_derivation path values_),<br />are compromised. Said hot master=
 secret can itself be the child derivative of a<br />cold master key. The m=
aster key for deriving the secret values need not be stored<br />online nor=
 with the derivation path keys and may be provided just-in-time by the<br /=
>application.<br /><br />Moreover, _generalized derivation paths_ may be in=
terpreted not simply as an<br />input to key derivation but also as informa=
tion about the real world.=C2=A0<br /></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/6d012560-4a66-4346-a1e8-8d8e5c879b29n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/6d012560-4a66-4346-a1e8-8d8e5c879b29n%40googlegroups.com</a>.=
<br />

------=_Part_161069_700989787.1716861890607--

------=_Part_161068_542952046.1716861890607--