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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <me@ricmoo.com>) id 1Wu44W-0006Bi-Jc
for bitcoin-development@lists.sourceforge.net;
Mon, 09 Jun 2014 18:13:28 +0000
X-ACL-Warn:
Received: from mail-ig0-f177.google.com ([209.85.213.177])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wu44V-0002X9-84
for bitcoin-development@lists.sourceforge.net;
Mon, 09 Jun 2014 18:13:28 +0000
Received: by mail-ig0-f177.google.com with SMTP id l13so4160815iga.10
for <bitcoin-development@lists.sourceforge.net>;
Mon, 09 Jun 2014 11:13:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:from:content-type:content-transfer-encoding
:subject:message-id:date:to:mime-version;
bh=XYAkG1hIAfMJ9Tg3Z+UG5uIcFj5U95cOMcPofvt/Ht0=;
b=fKwZtaUWD6avGY3OKo+04BaQT6FRA6bU48WfNClblbieb8VShC7nZzNArx5+NCv2HE
W7ig1aedUtWkHXYtp72TI1smW6d7z4+K99Q7Kmb+Rnky2KM21hmMLLoSGGyIDrlaGQPC
zJydkfFZZHqoisDGVbdn7Fka9E/n0DiWYD9eGkuEa1E4b5IXrKoJ20WNe17xKYeKeDqJ
r+KYjA/2bbmRK7YuKEMxlHlyNeR5Ie4jbtz3tGd1zNAr7dhoiiGrHCao6LZtnyeUtIy6
ESXjcaTkn3bbNscti0LgyfPVtsPHR8KckDwpyiZGWiN1e6VN2MgQ9QexWVAQ+y962TBP
2aYg==
X-Gm-Message-State: ALoCoQnQ/8Cu5KWgdMFHbAyB0+2UQaGUqG75Yl5YHElic7PZJMHrTRCd6YsRHhYJ+b+Tos/8SPzh
X-Received: by 10.42.88.135 with SMTP id c7mr21464030icm.46.1402337601328;
Mon, 09 Jun 2014 11:13:21 -0700 (PDT)
Received: from [192.168.2.22] (bas5-toronto47-2925108535.dsl.bell.ca.
[174.89.157.55])
by mx.google.com with ESMTPSA id j3sm58197169igx.8.2014.06.09.11.13.20
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Mon, 09 Jun 2014 11:13:20 -0700 (PDT)
From: Richard Moore <me@ricmoo.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <B1320E37-B63A-418A-9742-E2E967E71B14@ricmoo.com>
Date: Mon, 9 Jun 2014 14:13:19 -0400
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
X-Mailer: Apple Mail (2.1878.2)
X-Spam-Score: -0.1 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1Wu44V-0002X9-84
Subject: [Bitcoin-development] BIP38 Encrypted Address Discussion
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: Mon, 09 Jun 2014 18:13:28 -0000
Hey all again,
I am implementing BIP38 wallets right now, and had another idea I would =
like to put out there for discussion.
Right now the scrypt pbkdf is (16384, 8, 8) for (N, r, p), but I was =
wondering if it would make sense to include an extra byte in the address =
which would encode the parameters used? For now, they are fine, as it =
takes over 3 minutes to to hash once in my pure-Python implementation in =
CPython (3 seconds in pypy). But with all the latest scrypt mining ASICS =
hitting the market, and the difficulty rising of the scrypt alt coins, =
it may become more profitable in the future to try hacking wallets to =
gobble up their funds. Currently all the hardware is tuned for (1024, 1, =
1) and with adaptive-N, it only targets upgrading the N value, so having =
p =3Dr =3D 8 certainly means that hardware won=92t affect BIP 38=85 But =
who knows in the future if they start making Adaptive-N-r-p ASICS.
It also provides a way to vastly secure more important master keys=85 =
Maybe for a key that is cold storage of millions of dollars that won=92t =
be touched for multiple years, I don=92t mind waiting an hour on =
commodity hardware to decrypt it.
I was thinking, for example, if we used 1 byte, c, we could use a =
formula:
N =3D 2 ** (c + 11)
r =3D 2 ** c
p =3D r
Although, even a full byte is overkill=85 Maybe we can use the top three =
bits for something else? With 5 bits, the space becomes:
c =3D 0 =3D> (1024, 1, 1) (same as scrypt mining, albeit requires twice =
the dkLength)
c =3D 3 =3D> (16384, 8, 8) (current specs)
c =3D 31 =3D> (2199023255552,2147483648, 2147483648) (highest =
difficulty, requiring (5.6 * 10 ** 12) Gigabytes of memory per hash)
Anyways, just thinking out loud=85 I think even this space is too large=85=
We could also use the top 5 bits for N and lower 3 bits of r, p, if =
more granularity seems more useful (maybe somebody *wants* their =
passwords easy to parallelize but still difficult to break?)
N =3D 2 ** (10 + ((c >> 3) & 0x1f))
r =3D p =3D 2 ** ((c & 0x07) * 3)
Would put N =3D [1024, 2048, ..., 2199023255552] and r =3D p =3D [1, 8, =
64, 512, ..., 2097152]
The biggest issue would be backwards compatibility. The 6P should =
obviously stay the same, as it =93requires something extra=94 and the =
thing required is a passphrase. But maybe we could use one of the =
reserved bits to indicate that the address is adaptive? The decoded =
length of the address will also change though, which could pose issues =
if, for example, bounds checks aren=92t being done (bad, but it happens) =
or in the case of things like python implementations, might assume the =
length correct an use derived_half2 =3D decoded[23:] which would now =
come back with the last byte of derived_half1 and be one byte too long, =
unchecked, passed into AES, an exception is raised because it is not one =
16-byte block. These however seem assumptions that the developer should =
guard against.
This would retain backward compatibility though, as without the adaptive =
bit set, new and old implementations can decode the address fine (new =
implementations assuming c =3D 3); new implementations can detect the =
adaptive bit and select the correct kdrf parameters. old implementations =
on adaptive addresses would hopefully fail upon seeing the length is =
wrong or that the reserved bits are not 0, otherwise the checksum should =
fail=85 But if it does by some 1 in 4 billion chance match, the wallet =
may successfully import a newly created private key and address=85 Does =
this seem likely, or are current implementations ensuring the decoded =
length and bits are set to 0?
Otherwise, we *could* if all else fails, use =936A=94 for adaptive, or =
=936p=94=85 But I don=92t really like polluting the namespace for a =
minor tweak.
Randomly,
RicMoo
.=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`=
=B7.=B8=B8.=B7=B4=AF`=B7.=B8><(((=BA>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo@geneticmistakes.com
www: http://GeneticMistakes.com
|
