From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WNqOQ-00051Y-8d for bitcoin-development@lists.sourceforge.net; Wed, 12 Mar 2014 21:08:50 +0000 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; Received: from st11p02mm-asmtp002.mac.com ([17.172.220.237]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WNqOP-00059V-An for bitcoin-development@lists.sourceforge.net; Wed, 12 Mar 2014 21:08:50 +0000 Received: from st11p02mm-spool002.mac.com ([17.172.220.247]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTP id <0N2C00HY1DE9AL20@st11p02mm-asmtp002.mac.com> for bitcoin-development@lists.sourceforge.net; Wed, 12 Mar 2014 21:08:34 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87,1.0.14,0.0.0000 definitions=2014-03-12_07:2014-03-12, 2014-03-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1401130000 definitions=main-1403120125 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_PU1YwDCTYPlEml5P+SxP/w)" Received: from localhost ([17.172.220.223]) by st11p02mm-spool002.mac.com (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTP id <0N2C002EUDE9WV90@st11p02mm-spool002.mac.com>; Wed, 12 Mar 2014 21:08:33 +0000 (GMT) To: Pavol Rusnak From: Jean-Paul Kogelman Date: Wed, 12 Mar 2014 21:08:33 +0000 (GMT) X-Mailer: iCloud MailClient14A49 MailServer14A.15417 X-Originating-IP: [159.153.138.53] Message-id: <994afcd1-798d-452a-850c-02b5ce393dd3@me.com> In-reply-to: <5320C27B.8090205@gk2.sk> X-Spam-Score: -0.5 (/) 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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-Headers-End: 1WNqOP-00059V-An Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 21:08:50 -0000 --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 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


On Mar 12, 2014, at 01:24 PM, Pavol Rusnak <stick@gk2.sk&g= t; wrote:

On 03/12/2014 09:10 PM, William Yager wrote:<= br>
implement this is= to allow semi-trusted devices (like desktop PCs) to do
all the "heavy lifting". T= he way the spec is defined, it is easy to have a
more powerful device do all the t= ough key stretching work without
significantly compromising the security of the wa= llet.

By disclosing "preH" to compromised computer (betwe= en steps 4 and 5) you
make further steps 5-9 quite less important.
 
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.

If people feel strongly about this vulnerability, we can revi= sit step 4 and adjust it to make password recovery more expensive.<= /div>

jp
= --Boundary_(ID_/ezT6xeHVXjD2nriQVNfSA)-- --Boundary_(ID_PU1YwDCTYPlEml5P+SxP/w)--