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; 
MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet
 root key with optional encryption
Precedence: list

--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">&lt;<a href=3D"mailto:stick@gk2.sk" target=3D"_blank">stick@gk2.sk</a=
>&gt;</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>
&gt; The proposed BIP uses a bloom filter, so it has both plausible deniabi=
lity *and<br>
&gt; *typo checking. The bloom filter is optimized for two elements and wil=
l<br>
<div class=3D"">&gt; catch something like 99.9975% of typos, despite allowi=
ng two different<br>
&gt; passwords.<br>
<br>
</div>Ok, I see. So the spec allows one real and one fake password. That is=
<br>
something I don&#39;t consider plausible deniability. I am not saying that<=
br>
this solution is wrong, I find it quite interesting, but it&#39;s not<br>
plausible deniability. ;-)<br></blockquote><div><br></div><div>It&#39;s a l=
ittle more nuanced than that. There are *always* at least two passwords. If=
 the user doesn&#39;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>
&gt;&gt; I&#39;m afraid one would end up with code generated in one client =
that is<br>
&gt;&gt; unusable in a different client, because the client&#39;s developer=
 thought<br>
&gt;&gt; that using fancier algorithm instead of the proposed ones was a go=
od idea.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt; 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 &quot;outsourcing&quot; 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 &quot;heavy lifting&quot;. 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--