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
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam.back@gmail.com>) id 1VW4m3-0007xy-Oy
for bitcoin-development@lists.sourceforge.net;
Tue, 15 Oct 2013 13:35:00 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.83.45 as permitted sender)
client-ip=74.125.83.45; envelope-from=adam.back@gmail.com;
helo=mail-ee0-f45.google.com;
Received: from mail-ee0-f45.google.com ([74.125.83.45])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VW4m1-00037O-02
for bitcoin-development@lists.sourceforge.net;
Tue, 15 Oct 2013 13:34:58 +0000
Received: by mail-ee0-f45.google.com with SMTP id c50so3999378eek.4
for <bitcoin-development@lists.sourceforge.net>;
Tue, 15 Oct 2013 06:34:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=date:from:to:cc:subject:message-id:mime-version:content-type
:content-disposition:user-agent;
bh=AO9yvEUE1sURfQV/RaOZFhLlbW1blCzRFidoDhhMHWM=;
b=ZA59ssg8HLouPOcCnCBxBfqHAxm2EraR+j3DMrjQxRzf5GzdoFR+rihmMHRM/dKeqC
YIUKnRGlfhNvXnMlv74JUf6za0H6JJwF84WOea3DkGHY7mCCpmB2dHf0RnS4GeshvCRT
4DKQHHjSGcX85EZFswlezJ5ixxAdsK+XgNs3hDjv7nKIzmTjx2/Dlub+pFq2fTWrnpZy
nB8VHJFriNvh4ZKZ6BzgfunapWccZld0mmwMAEdUlUwJ/vwbWK/jHoXm89oh5fvwTOQb
LnIs1uiC4zP0d8dkyq5TuVO0rhl9K+glsbgUmGtCKHQ/SHaaoyUwNkoachm01L1Xwyjm
AVog==
X-Received: by 10.14.204.195 with SMTP id h43mr80522eeo.111.1381844090581;
Tue, 15 Oct 2013 06:34:50 -0700 (PDT)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
by mx.google.com with ESMTPSA id
f49sm166681601eec.7.1969.12.31.16.00.00
(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Tue, 15 Oct 2013 06:34:49 -0700 (PDT)
Received: by netbook (Postfix, from userid 1000)
id 86A7F2E016D; Tue, 15 Oct 2013 15:34:49 +0200 (CEST)
Received: by flare (hashcash-sendmail, from uid 1000);
Tue, 15 Oct 2013 15:34:46 +0200
Date: Tue, 15 Oct 2013 15:34:46 +0200
From: Adam Back <adam@cypherspace.org>
To: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20131015133446.GA5690@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:131015:bitcoin-development@lists.sourceforge.net::k4SymqqvL1A9d
TVg:000000000000000000003m8v
X-Hashcash: 1:20:131015:adam@cypherspace.org::pg4Ksao6nnql0cKl:00000000000000000
000000000000000000000000J/Ic
X-Spam-Score: -1.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(adam.back[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: bitcointalk.org]
X-Headers-End: 1VW4m1-00037O-02
Subject: [Bitcoin-development] two comments on brain-wallet security (and
BIP 38)
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: Tue, 15 Oct 2013 13:35:00 -0000
So I had a go at deciphering BIP 038 in summary what I think its doing is
(ommitting lot and sequence and deterinistic IVs for simplicity):
user:
x1 = Scrypt( salt=random, pass )
P = x1*G
send (salt, P) to coin manufacturer ->
manufacturer:
x2 = random 24bytes
Q = x2*P
k = Scrypt( salt2=H(Q)||salt, pass=P )
e = AES_k( x2 )
manufacturer puts es inside coin.
<- send coin, (salt, e, Q) to user
then optionally creates conf code:
B = x2*G
c = AES_k( B )
<- send conf code c to user
verify code c:
(by recreating P, then k from Q & P, decrypt c to get B, check Q = x1*B)
x1 = Scrypt( salt, pass )
P = x1*G
k = Scrypt( salt2=H(Q)||salt, pass=P )
Which seems reasonable enough, however its unfortunate that you have to
repeat the Scrypt work at setup.
One thing that occurs to me eg as mentioned by Rivest et al in their
time-lock puzzle paper is that it is easy to create work, if you are ok with
parallelizable symmetric constructions (like scrypt(i) or PBKDF2(i) with i
iterations) without *doing* the work during setup.
It seems to me therefore that the above protocol could avoid the javascript
overhead issue that forces users to choose a weak iteration level if they
want to create the wallet in that way.
eg create a 32-bit random salt, replace scrypt(i=16384, salt, pass) with
scrypt(i=1,salt, pass) to be brute forced based on deleted salt. Immediate
2^32 = 4billion iteration salt without any significant setup cost. (Or if
you want to limit the parallelism say scrypt(i=65536, salt, pass) with a
deleted 16-bit salt. That should be parallelizable up to 65536 GPU cores
(32x 7970 chips).
Symmetric time-lock puzzles can achieve decrypt asymmetry without repeating
the work at setup...
(Rivest et al goes on to avoid using that symmetric construct with an RSA
related mechanism, because they are trying to lock information for an
approximate future date, rather than protected by a specific amount of
grinding work.)
I proposed a different blind (securely server-offloadable) deterministic
proof of work relating to (asymmetric RSA-style) time-lock puzzles. The
difference from time-lock is it is made blind (so the work can be securely
offloaded without the server learning your password or resulting key) and
can be easily made parallelizable also which is desirable for server
offload.
https://bitcointalk.org/index.php?topic=311000.new#new
I think that could take brain-wallets to a new level of security, if you
protect the amount by an amount of computation proportional to the value, eg
0.1% or 0.01% redemption cost paid to blind proof of work miners.
Adam
|
