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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <will.yager@gmail.com>) id 1WNpuI-0006pt-9F
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Mar 2014 20:37:42 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.177 as permitted sender)
client-ip=209.85.216.177; envelope-from=will.yager@gmail.com;
helo=mail-qc0-f177.google.com;
Received: from mail-qc0-f177.google.com ([209.85.216.177])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WNpuH-0001nR-Bb
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Mar 2014 20:37:42 +0000
Received: by mail-qc0-f177.google.com with SMTP id w7so80227qcr.8
for <bitcoin-development@lists.sourceforge.net>;
Wed, 12 Mar 2014 13:37:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.36.200 with SMTP id p66mr54530702qgp.54.1394656655829;
Wed, 12 Mar 2014 13:37:35 -0700 (PDT)
Received: by 10.140.31.135 with HTTP; Wed, 12 Mar 2014 13:37:35 -0700 (PDT)
In-Reply-To: <5320C27B.8090205@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>
<CAG8oi1PhrmCqciECGKNa+DPp3Q_NrHP=79xxzOTkCJ655b4HXg@mail.gmail.com>
<5320C27B.8090205@gk2.sk>
Date: Wed, 12 Mar 2014 15:37:35 -0500
Message-ID: <CAG8oi1OAYRgaMtoT8pMGNrcLomz9+dgi-7WKN285F0U4=LJSmQ@mail.gmail.com>
From: William Yager <will.yager@gmail.com>
To: Pavol Rusnak <stick@gk2.sk>
Content-Type: multipart/alternative; boundary=001a11c13c808e0d2504f46ecec7
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: 1WNpuH-0001nR-Bb
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:37:42 -0000
--001a11c13c808e0d2504f46ecec7
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Mar 12, 2014 at 3:24 PM, Pavol Rusnak <stick@gk2.sk> wrote:
> On 03/12/2014 09:10 PM, William Yager wrote:
> > 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.
>
> By disclosing "preH" to compromised computer (between steps 4 and 5) you
> make further steps 5-9 quite less important.
>
>
Yes, that was my chief complaint as well. A compromised computer removes
most of the extra security offered by key stretching (should you choose to
outsource the bulk of your key stretching).
However, I think we have a good compromise, which is the inclusion of a
number of PBKDF2-HMAC-SHA512 based KDFs. For anyone who doesn't want to
trust any external device, but also wants to use memory-contrained devices
(that group of people includes me), PBKDF2-HMAC-SHA512 is very easy to
implement even on devices that only have a few kB of RAM, and even though
our number of rounds is very aggressive (2^16 and 2^21), it will still run
in reasonable time even on very slow embedded ARM processors.
Will
--001a11c13c808e0d2504f46ecec7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Mar 12, 2014 at 3:24 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">
<div class=3D"">On 03/12/2014 09:10 PM, William Yager wrote:<br>
> implement this is to allow semi-trusted devices (like desktop PCs) to =
do<br>
> all the "heavy lifting". The way the spec is defined, it is =
easy to have a<br>
> more powerful device do all the tough key stretching work without<br>
> significantly compromising the security of the wallet.<br>
<br>
</div>By disclosing "preH" to compromised computer (between steps=
4 and 5) you<br>
make further steps 5-9 quite less important.<br><br>
<div class=3D"HOEnZb"><div class=3D"h5"><span style=3D"color:rgb(34,34,34)"=
></span></div></div></blockquote><div><br></div><div>Yes, that was my chief=
complaint as well. A compromised computer removes most of the extra securi=
ty offered by key stretching (should you choose to outsource the bulk of yo=
ur key stretching).</div>
<div><br></div><div>However, I think we have a good compromise, which is th=
e inclusion of a number of PBKDF2-HMAC-SHA512 based KDFs. For anyone who do=
esn't want to trust any external device, but also wants to use memory-c=
ontrained devices (that group of people includes me), PBKDF2-HMAC-SHA512 is=
very easy to implement even on devices that only have a few kB of RAM, and=
even though our number of rounds is very aggressive (2^16 and 2^21), it wi=
ll still run in reasonable time even on very slow embedded ARM processors.<=
/div>
<div><br></div><div>Will</div></div><br></div></div>
--001a11c13c808e0d2504f46ecec7--
|
