1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
Return-Path: <Tobias@kaupat-hh.de>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9F433C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 May 2021 17:32:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 79EF983DFF
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 May 2021 17:32:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.105
X-Spam-Level:
X-Spam-Status: No, score=0.105 tagged_above=-999 required=5
tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 0Lgv_USwRjVE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 May 2021 17:32:24 +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 smtp1.osuosl.org (Postfix) with ESMTPS id 0EE1083DFB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 May 2021 17:32:22 +0000 (UTC)
Received: from mail-qv1-f41.google.com (mail-qv1-f41.google.com
[209.85.219.41]) (Authenticated sender: tobias@kaupat-hh.de)
by mail.worldserver.net (Postfix) with ESMTPSA id 6828E26D26
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 May 2021 19:32:18 +0200 (CEST)
Received: by mail-qv1-f41.google.com with SMTP id u1so1620544qvg.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 05 May 2021 10:32:17 -0700 (PDT)
X-Gm-Message-State: AOAM532KWp7aSiUZVOLml/6+NrsYF6Yked8QashNiibD9HEzpujRo5cz
D/Ncni8nxWEQV9MH1vVlZAgoGpptbI5do6vsO0M=
X-Google-Smtp-Source: ABdhPJwaGvgKeop4JaoSCdZUPU+69mWoTry1XdIBaCkg5DFVk8KzpINov/bk8EQAAVk+CuFMYkqTfftPHVp2pAJILl4=
X-Received: by 2002:a0c:f00d:: with SMTP id z13mr32197155qvk.0.1620235936947;
Wed, 05 May 2021 10:32:16 -0700 (PDT)
MIME-Version: 1.0
From: Tobias Kaupat <Tobias@kaupat-hh.de>
Date: Wed, 5 May 2021 19:32:05 +0200
X-Gmail-Original-Message-ID: <CAPyCnfvqVT00C2TZ86GXf856jNJqPXY0duRa1CfdCqC0ecC6xA@mail.gmail.com>
Message-ID: <CAPyCnfvqVT00C2TZ86GXf856jNJqPXY0duRa1CfdCqC0ecC6xA@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="0000000000007965ff05c198933f"
X-Mailman-Approved-At: Wed, 05 May 2021 19:38:49 +0000
Subject: [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: Wed, 05 May 2021 17:32:25 -0000
--0000000000007965ff05c198933f
Content-Type: text/plain; charset="UTF-8"
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
--0000000000007965ff05c198933f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi all,<div>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.</div><div><br><div><b>Use case:</b></div><div>An existi=
ng mnemonic (e.g. for a hardware wallet) should be saved on a paper backup =
in a password encrypted=C2=A0form. The encrypted=C2=A0form should be a mnem=
onic itself to keep all backup properties like error correction.</div><div>=
<br></div><div><b>Suggested=C2=A0solution:</b></div><div>1) Take the existi=
ng mnemonic and extract=C2=A0the related entropy</div><div>2) Create a SHA5=
26 hash (key) from a user defined password</div><div>3) Use the key as inpu=
t for an AES CTR (empty IV) to encrypt the entropy</div><div>4) Derive a ne=
w mnemonic from the encrypted entropy to be stored on a paper backup</div><=
div><br></div><div>We can add some hints to the paper backp that the mnemon=
ic=C2=A0is encrypted, or prefix it with "*" to make clear it'=
s not usable without applying the password via the algorithm above.</div><d=
iv><br></div><div>To restore the original mnemonic, one must know the passw=
ord and need to follow the process above again.</div><div><br></div><div>An=
example implementation=C2=A0in GoLang can be found here:</div><div><a href=
=3D"https://github.com/Niondir/go-bip39/blob/master/encyrption_test.go" tar=
get=3D"_blank">https://github.com/Niondir/go-bip39/blob/master/encyrption_t=
est.go</a><br></div><div><br></div><div><b>Why not use the existing BIP-39 =
Passphrase?</b></div><div>When generating a mnemonic=C2=A0with passphrase, =
the entropy is derived from the passphrase. When you have an existing mnemo=
nic 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 t=
o encrypt the entropy.</div><div><br></div><div>I'm open for your feedb=
ack. All encryption parameters are up to discussion and the whole proposal =
needs a security review. It's just the first draft.</div><div><br></div=
><div><b>Existing solutions</b></div><div>One solution I found is "See=
dshift" which can be found here: <a href=3D"https://github.com/mifunet=
oshiro/Seedshift">https://github.com/mifunetoshiro/Seedshift</a></div><div>=
<br></div><div>But I consider it less secure and I would like to suggest a =
solution based on provably secure algorithms rather than a "rot23 deri=
vation". Also using a date as password seems not very clever to me.</d=
iv><div><br></div><div>Kind regards<br>Tobias</div></div></div>
--0000000000007965ff05c198933f--
|
