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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
|
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 <eric@voskuil.org>) id 1YIoNf-0006aA-My
for bitcoin-development@lists.sourceforge.net;
Wed, 04 Feb 2015 01:03:47 +0000
X-ACL-Warn:
Received: from mail-pa0-f42.google.com ([209.85.220.42])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YIoNd-0006C1-Ea
for bitcoin-development@lists.sourceforge.net;
Wed, 04 Feb 2015 01:03:47 +0000
Received: by mail-pa0-f42.google.com with SMTP id bj1so103292440pad.1
for <bitcoin-development@lists.sourceforge.net>;
Tue, 03 Feb 2015 17:03:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:subject:references:in-reply-to:content-type;
bh=KlHzEF74GE9wHqDWgetb0RMek+zFAtCKsp0yS3baq84=;
b=c84GPCw6k5laLwaJDcmR0mCpe2UxIW0EJqYg2+vpXmAcOqM0gyMdytx97mHATa08Bf
VFwyYM4mF80wZiUJSSwvsiqRDYdqk5pn0rsJf/nlBLpldonr+B8Nn5abzLRnghm+1kLd
H7oN7Jah1c0XLSUD+SLN2uVGY5h8wDTDkT/5IcaMtOULl30iCNeY0g6rWxIIcNTV4f1q
nzkXqn4lWCnHiGXTpFAQXc1Oker40l0kohDnOO/soW5knmj9B/ySq84Xecv82LW7MCdi
hIj4GQ6NXm+gCa/YlRz8SB7WV+plt94sUFD+IC931DN8F1LdoUU4nsMMggilPjfKK7Du
SwJw==
X-Gm-Message-State: ALoCoQmqcICJJsqMEkQCTZI4AIupNwmWakxOGaDJ08RxGVlZLvdll3Bx4FRuwxHbqiNBCr0xUxho
X-Received: by 10.68.209.133 with SMTP id mm5mr43010062pbc.54.1423011819771;
Tue, 03 Feb 2015 17:03:39 -0800 (PST)
Received: from [10.0.1.3] (c-50-135-46-157.hsd1.wa.comcast.net.
[50.135.46.157])
by mx.google.com with ESMTPSA id bq7sm114354pdb.50.2015.02.03.17.03.38
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 03 Feb 2015 17:03:38 -0800 (PST)
Message-ID: <54D16FF9.2070200@voskuil.org>
Date: Tue, 03 Feb 2015 17:03:53 -0800
From: Eric Voskuil <eric@voskuil.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <etPan.54d0b945.46e87ccd.7f23@Williams-MBP>
In-Reply-To: <etPan.54d0b945.46e87ccd.7f23@Williams-MBP>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="mel0T6XPNSHCsinDo0dNWbdFW2Mt1bT3c"
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1YIoNd-0006C1-Ea
Subject: Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin
malware
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, 04 Feb 2015 01:03:47 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--mel0T6XPNSHCsinDo0dNWbdFW2Mt1bT3c
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 02/03/2015 04:04 AM, Will wrote:
> An idea for the bitcoin malware proposal below, the idea is at the bott=
om=85
> ...
> The trick we need to look at is how to use the bitcoin network as a
> delivery mechanism to bypass the need for the trusted third party in th=
e
> example above.=20
Using the Bitcoin network would be a convenience, certainly not a
requirement. Any public store (or other channel accessible to all
signers) would do.
> Instead of the second factor routing through a 3rd party
> to the intended recipient, we have another option - one that doesn=92t
> require core development either.
Absolutely, there is no need for a trusted third party in the case of
MFA unless that party has independent judgement in the decision to sign.
For example, if the third party is the trustee of a fund from which a
beneficiary wants to withdraw.
If you are just routing a decision back to yourself a third party makes
no sense. Oddly most of the services in operation today are doing just
that. You will end up authenticating to the third party from a platform
you control, which means that the platform must be trusted as much as
the third party. Why not just trust the platform and no third party? It
doesn't reduce the number of factors but it certainly reduces the attack
surface.
> 1) Sender > signs signature 1 via desktop > bitcoin network 2/3 P2SH
> 2) Mobile app also used by sender receives req. from bitcoin network to=
> sign signature - not through the site in 1 (similar to the 2nd channel
> between the website and security company above)
> 3) Sender > signs signature 2 via mobile app (or any separate
> device operating on a different network - heck could be radio) > 2/3
> signatures, transaction authorized
There's no need for the devices to be on independent networks. You can
safely remove that constraint. The partially-signed transaction can be
encrypted to the other signatories (for privacy) or it can be sent in
the clear. And ultimately all platforms in the scheme are connected to
the Internet, even if it's via sneakernet.
The important requirement is that the signing platforms are independent
and that the signers inspect the transactions on those platforms. This
preserves the benefit of MFA, which is that the signing platforms must
be compromised independently.
> ...
> If there was a way to perform 2/3 multisig without requiring a second
> band, performing the function safely by somehow knowing if the service
> is performed from a compromised device through some sort of
> on-blockchain anti-malware check by validating the signature of the
> signing application by comparing it to a signature recorded when the
> multisig address was funded, that would be a really neat breakthrough.=
> Food for thought, but I can=92t see how that could be executed in a wa=
y
> where signatures couldn=92t be spoofed from a compromised device. If
> someone cracks that problem, it=92s a really big advance for informatio=
n
> security.
Once you've done this you are talking about two independent signing
platforms. Plug two trustworthy signing devices into a PC and you've
done it. This is because the host environment (the PC in this case) is
not trusted in the first place. Two untrusted environments are no better
than one. It's only if the environments are trusted that they must be
independent.
But therein lies the problem. The physical proximity of two trusted
hardware devices exposes them to a single attack in the case of physical
theft or loss. So to guard against that threat the devices must be
independently stored. This presents a problem when it comes to usage.
This is the central problem of MFA. It's not possible to control
multiple factors while not exposing them to compromise. This is true
whether we are talking about multiple physical devices or a remote
service, since in the remote case the secret must still be accessible to
the person in control.
In the case of truly independent decisions MFA is strongest. But short
of that there's no reason for a remote third party. One can probably
accept the risk of securing multiple devices with the home, etc - and
needs to do this even if using a third party. On the other hand, walking
around with all necessary factors, or keeping them in the same safe, is
tantamount to having just one factor.
e
> On 02/02/2015 02:54 PM, Eric Voskuil wrote:=20
>> On Feb 2, 2015, at 11:53 AM
> <http://airmail.calendar/2015-02-02%2011:53:00%20MST>, Mike Hearn wrote=
:=20
>>>=20
>>> In sending the first-signed transaction to another for second=20
>>> signature, how does the first signer authenticate to the second=20
>>> without compromising the independence of the two factors?=20
>>>=20
>>> Not sure what you mean. The idea is the second factor displays the=20
>>> transaction and the user confirms it matches what they input to the=20
>>> first factor. Ideally, using BIP70, but I don't know if BA actually=20
>>> uses that currently.=20
>>>=20
>>> It's the same model as the TREZOR, except with a desktop app instead =
>>> of myTREZOR and a phone instead of a dedicated hardware device.=20
>>=20
>> Sorry for the slow reply, traveling.=20
>>=20
>> My comments were made in reference to this proposal:=20
>>=20
>>>> On Feb 2, 2015, at 10:40 AM
> <http://airmail.calendar/2015-02-02%2010:40:00%20MST>, Brian Erdelyi
> <brian.erdelyi@gmail.com <mailto:brian.erdelyi@gmail.com>=20
>>>> <mailto:brian.erdelyi@gmail.com>> wrote:=20
>>>>=20
>>>> Another concept...=20
>>>>=20
>>>> It should be possible to use multisig wallets to protect against=20
>>>> malware. For example, a user could generate a wallet with 3 keys and=
=20
>>>> require a transaction that has been signed by 2 of those keys. One=20
>>>> key is placed in cold storage and anther sent to a third-party.=20
>>>>=20
>>>> It is now possible to generate and sign transactions on the users=20
>>>> computer and send this signed transaction to the third-party for the=
=20
>>>> second signature. This now permits the use of out of band transactio=
n=20
>>>> verification techniques before the third party signs the transaction=
=20
>>>> and sends to the blockchain.=20
>>>>=20
>>>> If the third-party is malicious or becomes compromised they would no=
t=20
>>>> have the ability to complete transactions as they only have one=20
>>>> private key. If the third-party disappeared, the user could use the =
>>>> key in cold storage to sign transactions and send funds to a new wal=
let.=20
>>>>=20
>>>> Thoughts?=20
>=20
> My comments below start out with the presumption of user platform=20
> compromise, but the same analysis holds for the case where the user=20
> platform is clean but a web wallet is compromised. Obviously the idea i=
s=20
> that either or both may be compromised, but integrity is retained as=20
> long as both are not compromised and in collusion.=20
>=20
>> In the multisig scenario the presumption is of a user platform=20
>> compromised by malware. It envisions a user signing a 2 of 3 output wi=
th=20
>> a first signature. The precondition that the platform is compromised=20
>> implies that this process results in a loss of integrity of the privat=
e=20
>> key, and as such if it were not for the second signature requirement, =
>> the malware would be able to spend the output. This may be extended to=
=20
>> all of the keys in the wallet.=20
>>=20
>> The scenario envisions sending the signed transaction to an another=20
>> ("third") party. The objective is for the third party to provide the=20
>> second signature, thereby spending the output as intended by the user,=
=20
>> who is not necessarily the first signer. The send must be authenticate=
d=20
>> to the user. Otherwise the third party would have to sign anything it =
>> received, obviously rendering the second signature pointless. This=20
>> implies that the compromised platform must transmit a secret, or proof=
=20
>> of a secret, to the third party.=20
>>=20
>> The problem is that the two secrets are not independent if the first=20
>> platform is compromised. So of course the malware has the ability to=20
>> sign, impersonate the user and send to the third party. So the third=20
>> party *must* send the transaction to an *independent* platform for=20
>> verification by the user, and obtain consent before adding the second =
>> signature. The user, upon receiving the transaction details, must be=20
>> able to verify, on the independent platform, that the details match=20
>> those of the transaction that user presumably signed. Even for simple =
>> transactions this must include amount, address and fees.=20
>>=20
>> The central assumptions are that, while the second user platform may b=
e=20
>> compromised, the attack against the second platform is not coordinated=
=20
>> with that of the first, nor is the third party in collusion with the=20
>> first platform.=20
>>=20
>> Upon these assumptions rests the actual security benefit (increased=20
>> difficulty of the coordinated attack). The strength of these assumptio=
ns=20
>> is an interesting question, since it is hard to quantify. But without =
>> independence the entire security model is destroyed and there is thus =
no=20
>> protection whatsoever against malware.=20
>>=20
>> So for example a web-based or other third-party-provisioned=20
>> implementation of the first platform breaks the anti-collusion=20
>> assumption. Also, weak comsec allows an attack against the second=20
>> platform to be carried out against its network. So for example a simpl=
e=20
>> SMS-based confirmation could be executed by the first platform alone a=
nd=20
>> thereby also break the the anti-collusion assumption. This is why I=20
>> asked how independence is maintained.=20
>>=20
>> The assumption of a hardware wallet scenario is that the device itself=
=20
>> is not compromised. So the scenario is not the same. If the user signs=
=20
>> with a hardware wallet, nothing can collude with that process, with on=
e=20
>> caveat.=20
>>=20
>> While a hardware wallet is not subject to onboard malware, it is not=20
>> inconceivable that its keys could be extracted through probing or othe=
r=20
>> direct attack against the hardware. It's nevertheless an assumption of=
=20
>> hardware wallets that these attacks require loss of the hardware.=20
>> Physical possession constitutes compromise. So the collusion model wit=
h=20
>> a hardware wallet does exist, it just requires device possession.=20
>> Depending on the implementation the extraction may require a non-trivi=
al=20
>> amount of time and money.=20
>>=20
>> In a scenario where the user signs with HW, then sends the transaction=
=20
>> to a third party for a second of three signatures, and finally to a=20
>> second platform for user verification, a HW thief needs to collude wit=
h=20
>> the third party or the second platform before the owner becomes aware =
of=20
>> the theft (notifying the third party). This of course implies that=20
>> keeping both the fist and second platforms in close proximity=20
>> constitutes collusion from a physical security standpoint. This is=20
>> probably sufficient justification for not implementing such a model,=20
>> especially given the cost and complexity of stealing and cracking a=20
>> well-designed device. A device backup would provide comparable time to=
=20
>> recover with far less complexity (and loss of privacy).=20
>>=20
>> Incidentally the hardware wallet idea breaks down once any aspect of t=
he=20
>> platform or network to which it connects must be trusted, so for these=
=20
>> purposes I do not consider certain hybrid models as hardware wallets a=
t=20
>> all. For example one such device trusts that the compromised computer =
>> does not carry out a MITM attack between the signing device and a shar=
ed=20
>> secret entered in parts over time by the user. This reduces to a singl=
e=20
>> factor with no protection against a compromised platform.=20
>>=20
>> Of course these questions address integrity, not privacy. Use of a thi=
rd=20
>> party implies loss of privacy to that party, and with weak comsec to t=
he=20
>> network. Similarly, use of hardware signing devices implies loss of=20
>> privacy to the compromised platforms with which they exchange transact=
ions.=20
>>=20
>> e=20
>=20
> -------------- next part --------------=20
> A non-text attachment was scrubbed...=20
> Name: signature.asc=20
> Type: application/pgp-signature=20
> Size: 473 bytes=20
> Desc: OpenPGP digital signature=20
>=20
> ------------------------------=20
>=20
> Message: 3=20
> Date: Mon, 2 Feb 2015
> <http://airmail.calendar/2015-02-02%2012:00:00%20MST> 16:44:37 -0800
> <http://airmail.calendar/2015-02-03%2017:44:37%20MST>=20
> From: Pieter Wuille <pieter.wuille@gmail.com
> <mailto:pieter.wuille@gmail.com>>=20
> Subject: Re: [Bitcoin-development] [softfork proposal] Strict DER=20
> signatures=20
> To: Gregory Maxwell <gmaxwell@gmail.com <mailto:gmaxwell@gmail.com>>=20
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net
> <mailto:bitcoin-development@lists.sourceforge.net>>=20
> Message-ID:=20
> <CAPg+sBjjYLf4NZ8ezK7ML_OO-e6C8_V1i12AXejjrgp+wFB-pg@mail.gmail.com
> <mailto:CAPg+sBjjYLf4NZ8ezK7ML_OO-e6C8_V1i12AXejjrgp+wFB-pg@mail.gmail.=
com>>=20
> Content-Type: text/plain; charset=3DISO-8859-1=20
>=20
> On Sun, Jan 25, 2015 at 6:48 AM, Gregory Maxwell <gmaxwell@gmail.com
> <mailto:gmaxwell@gmail.com>> wrote:=20
>> So I think we should just go ahead with R/S length upper bounds as=20
>> both IsStandard and in STRICTDER.=20
>=20
> I would like to fix this at some point in any case.=20
>=20
> If we want to do that, we must at least have signatures with too-long=20
> R or S values as non-standard.=20
>=20
> One way to do that is to just - right now - add a patch to 0.10 to=20
> make those non-standard. This requires another validation flag, with a =
> bunch of switching logic.=20
>=20
> The much simpler alternative is just adding this to BIP66's DERSIG=20
> right now, which is a one-line change that's obviously softforking. Is =
> anyone opposed to doing so at this stage?=20
>=20
> --=20
> Pieter=20
>=20
>=20
>=20
> ------------------------------=20
>=20
> Message: 4=20
> Date: Tue, 3 Feb 2015 02:21:24 +0000
> <http://airmail.calendar/2015-02-02%2019:21:24%20MST>=20
> From: Gregory Maxwell <gmaxwell@gmail.com <mailto:gmaxwell@gmail.com>> =
> Subject: Re: [Bitcoin-development] [softfork proposal] Strict DER=20
> signatures=20
> To: Pieter Wuille <pieter.wuille@gmail.com
> <mailto:pieter.wuille@gmail.com>>=20
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net
> <mailto:bitcoin-development@lists.sourceforge.net>>=20
> Message-ID:=20
> <CAAS2fgQKbsaU5f+UPp8z2nEgXOfNhsFJoY=3D2j76ArXnBRsiV6g@mail.gmail.com
> <mailto:CAAS2fgQKbsaU5f+UPp8z2nEgXOfNhsFJoY=3D2j76ArXnBRsiV6g@mail.gmai=
l.com>>=20
> Content-Type: text/plain; charset=3DUTF-8=20
>=20
> On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille <pieter.wuille@gmail.com=
> <mailto:pieter.wuille@gmail.com>> wrote:=20
>> The much simpler alternative is just adding this to BIP66's DERSIG=20
>> right now, which is a one-line change that's obviously softforking. Is=
=20
>> anyone opposed to doing so at this stage?=20
>=20
> Thats my preference.=20
>=20
>=20
>=20
> ------------------------------=20
>=20
> Message: 5=20
> Date: Mon, 02 Feb 2015
> <http://airmail.calendar/2015-02-02%2012:00:00%20MST> 23:38:07 -0800
> <http://airmail.calendar/2015-02-04%2000:38:07%20MST>=20
> From: Eric Voskuil <eric@voskuil.org <mailto:eric@voskuil.org>>=20
> Subject: Re: [Bitcoin-development] Proposal to address Bitcoin malware =
> To: Brian Erdelyi <brian.erdelyi@gmail.com
> <mailto:brian.erdelyi@gmail.com>>=20
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net
> <mailto:bitcoin-development@lists.sourceforge.net>>=20
> Message-ID: <54D07ADF.8060809@voskuil.org
> <mailto:54D07ADF.8060809@voskuil.org>>=20
> Content-Type: text/plain; charset=3D"utf-8"=20
>=20
> On 02/02/2015 11:58 AM, Brian Erdelyi wrote:>=20
>>>Confusing or not, the reliance on multiple signatures as offering=20
>>>greater security than single relies on the independence of multiple=20
>>secrets. If the secrets cannot be shown to retain independence in the=20
>>>envisioned threat scenario (e.g. a user's compromised operating=20
>>>system) then the benefit reduces to making the exploit more difficult =
>>>to write, which, once written, reduces to no benefit. Yet the user=20
>>>still suffers the reduced utility arising from greater complexity,=20
>>>while being led to believe in a false promise.=20
>>=20
>>Just trying to make sure I understand what you?re saying. Are you=20
>>eluding to that if two of the three private keys get compromised there =
>>is no gain in security? Although the likelihood of this occurring is=20
>>lower, it is possible.=20
>=20
> No, that's not it. Sorry for not being clear. Independence of control i=
s=20
> the central issue in the analysis of a multiple factor system. If an=20
> attack compromises one factor there must be no way for that attack to=20
> reduce the difficulty of obtaining the other factors.=20
>=20
> Some factors (secrets), like a fingerprint, aren't very secret at all. =
> But getting someone's fingerprint doesn't also help the attacker get a =
> PIN. That factor must be attacked independently. But if the PIN is=20
> encrypted with the fingerprint in a public store, then the PIN is not=20
> independent of the fingerprint and there is really only one secret.=20
>=20
> If multiple factors are coincident (located within the same security=20
> perimeter) they are compromized coincidentally. Coincidence has the sam=
e=20
> effect as dependence. Consider a credit card with a "security code"=20
> printed on the back. A successful attack on the leather wallet yields=20
> both secrets.=20
>=20
> Individual environments can be compromised with some difficulty (e.g.=20
> desktop malware, fingerprint lift, dictionary attack, brute force PIN, =
> etc.). For the sake of simplicity, let that chance of successful=20
> independent attack on any factor be 1 in 2 and the resulting probabilit=
y=20
> of successful concurrent attack on any n factors be 1 in 2^n. If m=20
> factors are dependent/coincident on others the relation becomes 1 in=20
> 2^(n-m).=20
>=20
> Any multi-factor web wallet that handles the user's keys in the browser=
=20
> and authenticates the user in the browser to authorize service signing =
> is effectively single factor. One attack may be launched by an insider,=
=20
> or externally, against the web app, executing in the browser, gaining=20
> coincident access to two secrets. Browser/desktop malware can accomplis=
h=20
> the same. The difficulty is 1 in 2 vs. the expected 1 in 4.=20
>=20
>>As more malware targets bitcoins I think the utility is evident.=20
>>Given how final Bitcoin transactions are, I think it?s worth trying to =
>>find methods to help verify those transactions (if a user deems it to=20
>>be high-risk enough) before the transaction is completed. The balance=20
>>is trying to devise something that users do not find too burdensome.=20
>=20
> I'm not questioning the motive, I agree it's worth trying. But trying i=
s=20
> not succeeding. Increasing user (and/or system) complexity without=20
> increasing integrity or privacy is a poor trade, and worse if the user =
> is misled.=20
>=20
> e=20
>=20
> -------------- next part --------------=20
> A non-text attachment was scrubbed...=20
> Name: signature.asc=20
> Type: application/pgp-signature=20
> Size: 473 bytes=20
> Desc: OpenPGP digital signature=20
>=20
> ------------------------------=20
>=20
> -----------------------------------------------------------------------=
-------=20
> Dive into the World of Parallel Programming. The Go Parallel Website,=20
> sponsored by Intel and developed in partnership with Slashdot Media, is=
> your=20
> hub for all things parallel software development, from weekly thought=20
> leadership blogs to news, videos, case studies, tutorials and more. Tak=
e a=20
> look and join the conversation now. http://goparallel.sourceforge.net/ =
>=20
> ------------------------------=20
>=20
> _______________________________________________=20
> Bitcoin-development mailing list=20
> Bitcoin-development@lists.sourceforge.net
> <mailto:Bitcoin-development@lists.sourceforge.net>=20
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development=20
>=20
>=20
> End of Bitcoin-development Digest, Vol 45, Issue 11=20
> ***************************************************=20
>=20
>=20
>=20
>=20
> -----------------------------------------------------------------------=
-------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is=
your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Tak=
e a
> look and join the conversation now. http://goparallel.sourceforge.net/
>=20
>=20
>=20
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20
--mel0T6XPNSHCsinDo0dNWbdFW2Mt1bT3c
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJU0W/5AAoJEDzYwH8LXOFOZ00H/i7Z+/WajlRarOgXqvnwkjZH
zR5rCQZ/OklJYmB02oTM0Wj4KExoKd40No9tdoVKpavvZg8Bbu2SGOgFaN375XLR
EvyWdns0t5nvVXSsLNF34JVRObE/yyLVWUwUfHk8T/vf6k0KY+ZuXQz6d+m/+g4U
ywwvVVB6z8U4e/ey0/oQw90RszVQ8cHcrLpJ7ZHmeKbKP6YjuuVcovLjKlRs8ROs
DWc63yYShGIcaItauGydbrcYP6xI82ExqX8y06OWiBYGvBZQ/FqYso1Axs4/qF7T
aCW/vx32ol2irD1NHxklTMGhH3P22Hdzy2ml+JrhBpa2SpN0ZZQzvCCZPtDcY2M=
=GA48
-----END PGP SIGNATURE-----
--mel0T6XPNSHCsinDo0dNWbdFW2Mt1bT3c--
|