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
|
Return-Path: <yanmaani@cock.li>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id EB501C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 May 2021 22:54:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id C596940459
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 May 2021 22:54:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 2.026
X-Spam-Level: **
X-Spam-Status: No, score=2.026 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_PBL=3.335,
RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=no autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=cock.li
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id GrkQJLa9aD2C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 May 2021 22:54:31 +0000 (UTC)
X-Greylist: delayed 00:05:26 by SQLgrey-1.8.0
Received: from mail.cock.li (unknown [37.120.193.122])
by smtp2.osuosl.org (Postfix) with ESMTPS id 6BCA0400E9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 May 2021 22:54:29 +0000 (UTC)
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail;
t=1620514141; bh=NN1exsZ4oEF7MGc0lJwsBSCoj70EGrxIP5VSgvjgFRo=;
h=Date:From:To:Subject:In-Reply-To:References:From;
b=yh700+KCCMGT2GKBMcIEYLPnEHIKlE3/7HCEPHPc8Y4CLgotAGpUlpb4rYM52hDf6
3IxPjZwspsHv0rdPSWV5IUzfhEUs4GVQyHvX0q/1pg+PipWnN2lRnMjBMvFGttkD5b
y3+uPt+wvOPZjEm3Sds6VjOke/nH+8K18DEAI9Phrkn0UwLPzf2xfZ512A3e1Qnfrx
6E4RGHkNh1YYKqv7ebLCCHNP+MZDlQi6lVOauOunI0Ozy5PfFKfc9s0Czd6HAd8Ahm
V+XFgf+Cb/4joheMzUAN9/gzwBXFE1kBZ6M7D/jt/yWBC8ogqk+LDXns90GDXluejW
QH67RGIr1eRfw==
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Sat, 08 May 2021 22:49:01 +0000
From: yanmaani@cock.li
To: Tobias Kaupat <Tobias@kaupat-hh.de>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAPyCnfvqVT00C2TZ86GXf856jNJqPXY0duRa1CfdCqC0ecC6xA@mail.gmail.com>
References: <CAPyCnfvqVT00C2TZ86GXf856jNJqPXY0duRa1CfdCqC0ecC6xA@mail.gmail.com>
Message-ID: <6e325fc7954d34b75e3c1cf7590d0395@cock.li>
X-Sender: yanmaani@cock.li
User-Agent: Roundcube Webmail/1.3.15
X-Mailman-Approved-At: Sat, 08 May 2021 22:57:39 +0000
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: Sat, 08 May 2021 22:54:36 -0000
Why the existing mnemonic? If you've already dealt with unencrypted
material carelessly, the genie is out of the bottle. And if you're OK
with making a new one, why not just use BIP-39 passphrases to begin
with?
If you must, it seems like a decent way to accomplish it, but raw
SHA-256 is probably not the best choice. PBKDF2 like in the BIP-39 spec
is tried and true, or something like scrypt. This would however change
the storage format - you'd have to store a salt too, making your
mnemonic bigger.
On 2021-05-05 17:32, Tobias Kaupat via bitcoin-dev 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
|
