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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <will.yager@gmail.com>) id 1WNpU2-0006C4-28
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Mar 2014 20:10:34 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.173 as permitted sender)
client-ip=209.85.216.173; envelope-from=will.yager@gmail.com;
helo=mail-qc0-f173.google.com;
Received: from mail-qc0-f173.google.com ([209.85.216.173])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WNpU1-0006od-BD
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Mar 2014 20:10:34 +0000
Received: by mail-qc0-f173.google.com with SMTP id r5so14339qcx.32
for <bitcoin-development@lists.sourceforge.net>;
Wed, 12 Mar 2014 13:10:27 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.23.209 with SMTP id 75mr11931250qgp.89.1394655027910;
Wed, 12 Mar 2014 13:10:27 -0700 (PDT)
Received: by 10.140.31.135 with HTTP; Wed, 12 Mar 2014 13:10:27 -0700 (PDT)
In-Reply-To: <5320BDD1.50001@gk2.sk>
References: <44fcb02b-3784-45a6-816a-312c78d940cd@me.com>
<5320B7F1.8060701@gk2.sk>
<CAG8oi1M_jnn9vzHjN5h+0x-dYEKudgJ-DEqOKrdv-sCDaFV3NA@mail.gmail.com>
<5320BDD1.50001@gk2.sk>
Date: Wed, 12 Mar 2014 15:10:27 -0500
Message-ID: <CAG8oi1PhrmCqciECGKNa+DPp3Q_NrHP=79xxzOTkCJ655b4HXg@mail.gmail.com>
From: William Yager <will.yager@gmail.com>
To: Pavol Rusnak <stick@gk2.sk>
Content-Type: multipart/alternative; boundary=001a11c1342285dbd204f46e6d0d
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(will.yager[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WNpU1-0006od-BD
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet
root key with optional encryption
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 12 Mar 2014 20:10:34 -0000
--001a11c1342285dbd204f46e6d0d
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Mar 12, 2014 at 3:04 PM, Pavol Rusnak <stick@gk2.sk> wrote:
> On 03/12/2014 08:55 PM, William Yager wrote:
> > The proposed BIP uses a bloom filter, so it has both plausible
> deniability *and
> > *typo checking. The bloom filter is optimized for two elements and will
> > catch something like 99.9975% of typos, despite allowing two different
> > passwords.
>
> Ok, I see. So the spec allows one real and one fake password. That is
> something I don't consider plausible deniability. I am not saying that
> this solution is wrong, I find it quite interesting, but it's not
> plausible deniability. ;-)
>
It's a little more nuanced than that. There are *always* at least two
passwords. If the user doesn't want a second password, a random one is
generated for them. A wallet with two known encryption keys and only one
known encryption key are indistinguishable. If compelled to decrypt, there
is no way to prove that the user actually knows a second password.
>
> >> I'm afraid one would end up with code generated in one client that is
> >> unusable in a different client, because the client's developer thought
> >> that using fancier algorithm instead of the proposed ones was a good
> idea.
> >>
> >>
> > This is clearly in violation of the spec.
>
> Ah, I misunderstood. I thought that outsourcing the KDF means allowing
> the 3rd party to use any KDF instead of the specified ones. What would
> be the reason to outsource if this is not possible, anyway?
>
>
Yes, the "outsourcing" terminology is a little confusing. The idea is this:
You have a little device, like a Trezor. It has very little RAM and very
little CPU power. However, you want to use a powerful key-stretching
algorithm (like the maximum Scrypt KDF defined in the spec). One way to
implement this is to allow semi-trusted devices (like desktop PCs) to do
all the "heavy lifting". The way the spec is defined, it is easy to have a
more powerful device do all the tough key stretching work without
significantly compromising the security of the wallet.
Will
--001a11c1342285dbd204f46e6d0d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Mar 12, 2014 at 3:04 PM, Pavol Rusnak <span dir=3D=
"ltr"><<a href=3D"mailto:stick@gk2.sk" target=3D"_blank">stick@gk2.sk</a=
>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
On 03/12/2014 08:55 PM, William Yager wrote:<br>
> The proposed BIP uses a bloom filter, so it has both plausible deniabi=
lity *and<br>
> *typo checking. The bloom filter is optimized for two elements and wil=
l<br>
<div class=3D"">> catch something like 99.9975% of typos, despite allowi=
ng two different<br>
> passwords.<br>
<br>
</div>Ok, I see. So the spec allows one real and one fake password. That is=
<br>
something I don't consider plausible deniability. I am not saying that<=
br>
this solution is wrong, I find it quite interesting, but it's not<br>
plausible deniability. ;-)<br></blockquote><div><br></div><div>It's a l=
ittle more nuanced than that. There are *always* at least two passwords. If=
the user doesn't want a second password, a random one is generated for=
them. A wallet with two known encryption keys and only one known encryptio=
n key are indistinguishable. If compelled to decrypt, there is no way to pr=
ove that the user actually knows a second password.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
<div class=3D""><br>
>> I'm afraid one would end up with code generated in one client =
that is<br>
>> unusable in a different client, because the client's developer=
thought<br>
>> that using fancier algorithm instead of the proposed ones was a go=
od idea.<br>
>><br>
>><br>
> This is clearly in violation of the spec.<br>
<br>
</div>Ah, I misunderstood. I thought that outsourcing the KDF means allowin=
g<br>
the 3rd party to use any KDF instead of the specified ones. What would<br>
be the reason to outsource if this is not possible, anyway?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>Yes, the "outsourcing" terminology is a little conf=
using. The idea is this: You have a little device, like a Trezor. It has ve=
ry little RAM and very little CPU power. However, you want to use a powerfu=
l key-stretching algorithm (like the maximum Scrypt KDF defined in the spec=
). One way to implement this is to allow semi-trusted devices (like desktop=
PCs) to do all the "heavy lifting". The way the spec is defined,=
it is easy to have a more powerful device do all the tough key stretching =
work without significantly compromising the security of the wallet.</div>
<div><br></div><div>Will=A0</div></div><br></div></div>
--001a11c1342285dbd204f46e6d0d--
|
