path: root/da/18aa64d5ed42e2364c39d07b36017f27ab8cf5

Return-Path: <Tobias@kaupat-hh.de>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E80BEC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  6 May 2021 14:10:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id C2EDF405CF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  6 May 2021 14:10:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001]
 autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id iObjLfwc1fhC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  6 May 2021 14:10:48 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.worldserver.net (mail.worldserver.net [217.13.200.37])
 by smtp4.osuosl.org (Postfix) with ESMTPS id A530F40597
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  6 May 2021 14:10:48 +0000 (UTC)
Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com
 [209.85.222.176]) (Authenticated sender: tobias@kaupat-hh.de)
 by mail.worldserver.net (Postfix) with ESMTPSA id 4BB4F26CA7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  6 May 2021 16:10:44 +0200 (CEST)
Received: by mail-qk1-f176.google.com with SMTP id 76so4974447qkn.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 06 May 2021 07:10:44 -0700 (PDT)
X-Gm-Message-State: AOAM530gDO7uq3scveBnA8fXFSbfjrHVoKWo2wRmHr7W3vs1FN+Gl3Cp
 24Yfu2rxZhm2hAX36TIVp+yP9aA1HhcvB0Q9mtg=
X-Google-Smtp-Source: ABdhPJxHsgo/QK+h9BC9ikDHCMSpQO5Fa4wBEq2Sg6ln6V1E4UAdSIopVrcF4uVilDutFUcoXN/DSOdRXqkGLzaoju4=
X-Received: by 2002:a37:394:: with SMTP id 142mr4098344qkd.347.1620310243574; 
 Thu, 06 May 2021 07:10:43 -0700 (PDT)
MIME-Version: 1.0
References: <CAPyCnfvqVT00C2TZ86GXf856jNJqPXY0duRa1CfdCqC0ecC6xA@mail.gmail.com>
 <CAJowKg+bpobZq3KfqwO6Rb-tKNw_N-tXoXFE84SdE0jjnc6i3g@mail.gmail.com>
In-Reply-To: <CAJowKg+bpobZq3KfqwO6Rb-tKNw_N-tXoXFE84SdE0jjnc6i3g@mail.gmail.com>
From: Tobias Kaupat <Tobias@kaupat-hh.de>
Date: Thu, 6 May 2021 16:10:31 +0200
X-Gmail-Original-Message-ID: <CAPyCnfuPdxUa7xRKt+7q92jP3cG4wrjnU9SajwCf19Bc-8=A_w@mail.gmail.com>
Message-ID: <CAPyCnfuPdxUa7xRKt+7q92jP3cG4wrjnU9SajwCf19Bc-8=A_w@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>
Content-Type: multipart/alternative; boundary="0000000000007e896f05c1a9e0d0"
X-Mailman-Approved-At: Thu, 06 May 2021 15:48:29 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Encryption of an existing BIP39 mnemonic without
 changing the seed
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: Thu, 06 May 2021 14:10:51 -0000

--0000000000007e896f05c1a9e0d0
Content-Type: text/plain; charset="UTF-8"

Hello Erik,
Thanks for your reply.
After a little research I came to the same conclusion. PDKDF2 makes sense,
since it is already used in BIP39.
I will update my code.



Regarding SeedXOR:
That's at least a similar solution, but than I have to store 2 phrases, I
really like to keep one part in my head, which is only possible with a
password.
Plus for anyone who want to use two seeds my proposal also works - it just
needs software to be applied.

Kind regards
Tobias Kaupat



Erik Aronesty <erik@q32.com> schrieb am Do., 6. Mai 2021, 15:19:

> i would stretch the password, with pbkdf2 or argon2 with like 30k
> rounds or something first, rather than "just hashing it".  remember,
> it's pretty easy to validate these seeds - not like you lock someone
> out after 9 guesses!
>
> On Wed, May 5, 2021 at 3:38 PM Tobias Kaupat via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > Hi all,
> > I want to start a discussion about a use case I have and a possible
> solution. I have not found any satisfying solution to this use case yet.
> >
> > Use case:
> > An existing mnemonic (e.g. for a hardware wallet) should be saved on a
> paper backup in a password encrypted form. The encrypted form should be a
> mnemonic itself to keep all backup properties like error correction.
> >
> > Suggested solution:
> > 1) Take the existing mnemonic and extract the related entropy
> > 2) Create a SHA526 hash (key) from a user defined password
> > 3) Use the key as input for an AES CTR (empty IV) to encrypt the entropy
> > 4) Derive a new mnemonic from the encrypted entropy to be stored on a
> paper backup
> >
> > We can add some hints to the paper backp that the mnemonic is encrypted,
> or prefix it with "*" to make clear it's not usable without applying the
> password via the algorithm above.
> >
> > To restore the original mnemonic, one must know the password and need to
> follow the process above again.
> >
> > An example implementation in GoLang can be found here:
> > https://github.com/Niondir/go-bip39/blob/master/encyrption_test.go
> >
> > Why not use the existing BIP-39 Passphrase?
> > When generating a mnemonic with passphrase, the entropy is derived from
> the passphrase. When you have an existing mnemonic without a passphrase,
> any attempt to add a passphrase will end up in a different seed and thus a
> different private key. What we actually need is to encrypt the entropy.
> >
> > I'm open for your feedback. All encryption parameters are up to
> discussion and the whole proposal needs a security review. It's just the
> first draft.
> >
> > Existing solutions
> > One solution I found is "Seedshift" which can be found here:
> https://github.com/mifunetoshiro/Seedshift
> >
> > But I consider it less secure and I would like to suggest a solution
> based on provably secure algorithms rather than a "rot23 derivation". Also
> using a date as password seems not very clever to me.
> >
> > Kind regards
> > Tobias
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000007e896f05c1a9e0d0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>Hello Erik,</div><div dir=3D"auto">Thanks for your r=
eply.<br><div dir=3D"auto">After a little research I came to the same concl=
usion. PDKDF2 makes sense, since it is already used in BIP39.</div><div dir=
=3D"auto">I will update my code.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Regarding=
 SeedXOR:</div><div dir=3D"auto">That&#39;s at least a similar solution, bu=
t than I have to store 2 phrases, I really like to keep one part in my head=
, which is only possible with a password.=C2=A0</div><div dir=3D"auto">Plus=
 for anyone who want to use two seeds my proposal also works - it just need=
s software to be applied.</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">Kind regards</div><div dir=3D"auto">Tobias Kaupat</div><div dir=3D"auto">=
<br></div><br><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" =
class=3D"gmail_attr">Erik Aronesty &lt;<a href=3D"mailto:erik@q32.com" targ=
et=3D"_blank" rel=3D"noreferrer">erik@q32.com</a>&gt; schrieb am Do., 6. Ma=
i 2021, 15:19:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">i would stretch the =
password, with pbkdf2 or argon2 with like 30k<br>
rounds or something first, rather than &quot;just hashing it&quot;.=C2=A0 r=
emember,<br>
it&#39;s pretty easy to validate these seeds - not like you lock someone<br=
>
out after 9 guesses!<br>
<br>
On Wed, May 5, 2021 at 3:38 PM Tobias Kaupat via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"norefer=
rer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>=
&gt; wrote:<br>
&gt;<br>
&gt; Hi all,<br>
&gt; I want to start a discussion about a use case I have and a possible so=
lution. I have not found any satisfying solution to this use case yet.<br>
&gt;<br>
&gt; Use case:<br>
&gt; An existing mnemonic (e.g. for a hardware wallet) should be saved on a=
 paper backup in a password encrypted form. The encrypted form should be a =
mnemonic itself to keep all backup properties like error correction.<br>
&gt;<br>
&gt; Suggested solution:<br>
&gt; 1) Take the existing mnemonic and extract the related entropy<br>
&gt; 2) Create a SHA526 hash (key) from a user defined password<br>
&gt; 3) Use the key as input for an AES CTR (empty IV) to encrypt the entro=
py<br>
&gt; 4) Derive a new mnemonic from the encrypted entropy to be stored on a =
paper backup<br>
&gt;<br>
&gt; We can add some hints to the paper backp that the mnemonic is encrypte=
d, or prefix it with &quot;*&quot; to make clear it&#39;s not usable withou=
t applying the password via the algorithm above.<br>
&gt;<br>
&gt; To restore the original mnemonic, one must know the password and need =
to follow the process above again.<br>
&gt;<br>
&gt; An example implementation in GoLang can be found here:<br>
&gt; <a href=3D"https://github.com/Niondir/go-bip39/blob/master/encyrption_=
test.go" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https:/=
/github.com/Niondir/go-bip39/blob/master/encyrption_test.go</a><br>
&gt;<br>
&gt; Why not use the existing BIP-39 Passphrase?<br>
&gt; When generating a mnemonic with passphrase, the entropy is derived fro=
m the passphrase. When you have an existing mnemonic without a passphrase, =
any attempt to add a passphrase will end up in a different seed and thus a =
different private key. What we actually need is to encrypt the entropy.<br>
&gt;<br>
&gt; I&#39;m open for your feedback. All encryption parameters are up to di=
scussion and the whole proposal needs a security review. It&#39;s just the =
first draft.<br>
&gt;<br>
&gt; Existing solutions<br>
&gt; One solution I found is &quot;Seedshift&quot; which can be found here:=
 <a href=3D"https://github.com/mifunetoshiro/Seedshift" rel=3D"noreferrer n=
oreferrer noreferrer" target=3D"_blank">https://github.com/mifunetoshiro/Se=
edshift</a><br>
&gt;<br>
&gt; But I consider it less secure and I would like to suggest a solution b=
ased on provably secure algorithms rather than a &quot;rot23 derivation&quo=
t;. Also using a date as password seems not very clever to me.<br>
&gt;<br>
&gt; Kind regards<br>
&gt; Tobias<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"norefe=
rrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a=
><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lis=
ts.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>

--0000000000007e896f05c1a9e0d0--