Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of me.com
	designates 17.172.220.237 as permitted sender)
	client-ip=17.172.220.237; envelope-from=jeanpaulkogelman@me.com;
	helo=st11p02mm-asmtp002.mac.com; 
MIME-version: 1.0
Content-type: multipart/alternative;
	boundary="Boundary_(ID_PU1YwDCTYPlEml5P+SxP/w)"
To: Pavol Rusnak <stick@gk2.sk>
From: Jean-Paul Kogelman <jeanpaulkogelman@me.com>
Date: Wed, 12 Mar 2014 21:08:33 +0000 (GMT)
Message-id: <994afcd1-798d-452a-850c-02b5ce393dd3@me.com>
In-reply-to: <5320C27B.8090205@gk2.sk>
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


--Boundary_(ID_PU1YwDCTYPlEml5P+SxP/w)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: quoted-printable

=0A=0AOn Mar 12, 2014, at 01:24 PM, Pavol Rusnak <stick@gk2.sk> wrote:=0A=0A=
On 03/12/2014 09:10 PM, William Yager wrote:=0Aimplement this is to allow =
semi-trusted devices (like desktop PCs) to do=0Aall the "heavy lifting". T=
he way the spec is defined, it is easy to have a=0Amore powerful device do=
 all the tough key stretching work without=0Asignificantly compromising th=
e security of the wallet.=0A=0ABy disclosing "preH" to compromised compute=
r (between steps 4 and 5) you=0Amake further steps 5-9 quite less importan=
t.=0A=A0=0AAgreed, this is a valid concern. This could possibly allow a 3r=
d party to crack the password, but then again, they would not gain access =
to any key material. So yes, you could expose your password, but your key =
would still be safe.=0A=0AIf people feel strongly about this vulnerability=
, we can revisit step 4 and adjust it to make password recovery more expen=
sive.=0A=0Ajp=

--Boundary_(ID_PU1YwDCTYPlEml5P+SxP/w)
Content-type: multipart/related;
	boundary="Boundary_(ID_/ezT6xeHVXjD2nriQVNfSA)"; type="text/html"


--Boundary_(ID_/ezT6xeHVXjD2nriQVNfSA)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable

<html><body><div><br><br>On Mar 12, 2014, at 01:24 PM, Pavol Rusnak &lt;stick@gk2.sk&g=
t; wrote:<br><br></div><div><blockquote type=3D"cite"><div class=3D"msg-qu=
ote"><div class=3D"_stretch">On 03/12/2014 09:10 PM, William Yager wrote:<=
br><blockquote class=3D"quoted-plain-text" type=3D"cite">implement this is=
 to allow semi-trusted devices (like desktop PCs) to do</blockquote><block=
quote class=3D"quoted-plain-text" type=3D"cite">all the "heavy lifting". T=
he way the spec is defined, it is easy to have a</blockquote><blockquote c=
lass=3D"quoted-plain-text" type=3D"cite">more powerful device do all the t=
ough key stretching work without</blockquote><blockquote class=3D"quoted-p=
lain-text" type=3D"cite">significantly compromising the security of the wa=
llet.</blockquote><br> By disclosing "preH" to compromised computer (betwe=
en steps 4 and 5) you<br> make further steps 5-9 quite less important.</di=
v></div></blockquote><span>&nbsp;</span></div><div>Agreed, this is a valid=
 concern. This could possibly allow a 3rd party to crack the password, but=
 then again, they would not gain access to any key material. So yes, you c=
ould expose your password, but your key would still be safe.</div><div><sp=
an style=3D"line-height: 1.5;"><br></span></div><div><span style=3D"line-h=
eight: 1.5;">If people feel strongly about this vulnerability, we can revi=
sit step 4 and adjust it to make password recovery more expensive.</span><=
/div><div><span style=3D"line-height: 1.5;"><br></span></div><div><span st=
yle=3D"line-height: 1.5;">jp</span></div></body></html>=

--Boundary_(ID_/ezT6xeHVXjD2nriQVNfSA)--

--Boundary_(ID_PU1YwDCTYPlEml5P+SxP/w)--