diff options
| author | Jean-Paul Kogelman <jeanpaulkogelman@me.com> | 2014-03-12 21:08:33 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-03-12 21:08:50 +0000 |
| commit | 5ed31bd97c6e63d8403dea104c00d702b757688f (patch) | |
| tree | 74904bb0a03c1fe4aad755adbdd3f7e246b0d0b8 | |
| parent | 62edc14805d64c262f32cf1a03909c8cb524c2f4 (diff) | |
| download | pi-bitcoindev-5ed31bd97c6e63d8403dea104c00d702b757688f.tar.gz pi-bitcoindev-5ed31bd97c6e63d8403dea104c00d702b757688f.zip | |
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
| -rw-r--r-- | 34/fc09d736b373ff6d51157731447db6172868cf | 125 |
1 files changed, 125 insertions, 0 deletions
diff --git a/34/fc09d736b373ff6d51157731447db6172868cf b/34/fc09d736b373ff6d51157731447db6172868cf new file mode 100644 index 000000000..88a2abb64 --- /dev/null +++ b/34/fc09d736b373ff6d51157731447db6172868cf @@ -0,0 +1,125 @@ +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 <jeanpaulkogelman@me.com>) 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 <stick@gk2.sk> +From: Jean-Paul Kogelman <jeanpaulkogelman@me.com> +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 <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 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 <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 <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> </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)-- + + |