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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <ctpacia@gmail.com>) id 1XnAzL-00084Q-Tn
for bitcoin-development@lists.sourceforge.net;
Sat, 08 Nov 2014 18:43:55 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.171 as permitted sender)
client-ip=209.85.214.171; envelope-from=ctpacia@gmail.com;
helo=mail-ob0-f171.google.com;
Received: from mail-ob0-f171.google.com ([209.85.214.171])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XnAzK-0003RO-Ga
for bitcoin-development@lists.sourceforge.net;
Sat, 08 Nov 2014 18:43:55 +0000
Received: by mail-ob0-f171.google.com with SMTP id wp18so4098870obc.16
for <bitcoin-development@lists.sourceforge.net>;
Sat, 08 Nov 2014 10:43:49 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.202.8.193 with SMTP id 184mr880171oii.115.1415472228977;
Sat, 08 Nov 2014 10:43:48 -0800 (PST)
Received: by 10.202.71.129 with HTTP; Sat, 8 Nov 2014 10:43:48 -0800 (PST)
Received: by 10.202.71.129 with HTTP; Sat, 8 Nov 2014 10:43:48 -0800 (PST)
In-Reply-To: <CANEZrP3Pk3O3uFJtDkO9BfVogbaiWt1SmMrP02fRBpt3TtMrtg@mail.gmail.com>
References: <CANEZrP3Pk3O3uFJtDkO9BfVogbaiWt1SmMrP02fRBpt3TtMrtg@mail.gmail.com>
Date: Sat, 8 Nov 2014 13:43:48 -0500
Message-ID: <CAB+qUq6CxOZpdS+E7rpBmY=4VBiOr845096TUv7koaNXD8gAMg@mail.gmail.com>
From: Chris Pacia <ctpacia@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a113d1c7065d52d05075d4f55
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
(ctpacia[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: 1XnAzK-0003RO-Ga
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Update on mobile 2-factor wallets
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: Sat, 08 Nov 2014 18:43:56 -0000
--001a113d1c7065d52d05075d4f55
Content-Type: text/plain; charset=UTF-8
Thanks Mike I'll have to read that threshold signature paper.
I am familiar with the Princeton threshold signature but I was under the
impression a single key needed to be generated on a single device then
split and distributed.
Does this scheme work the same way?
I would have concerns about generating a key on a compromised computer.
On Nov 8, 2014 11:05 AM, "Mike Hearn" <mike@plan99.net> wrote:
> Here is a summary of current developments in the space of decentralised
> 2-factor Bitcoin wallets. I figured some people here might find it
> interesting.
>
> There has been very nice progress in the last month or two. Decentralised
> 2FA wallets run on a desktop/laptop and have a (currently always Android)
> smartphone app to go with them. Compromise of the wallet requires
> compromise of both devices.
>
> Alon Muroch and Chris Pacia have made huge progress on "Bitcoin
> Authenticator", their (HD) wallet app. The desktop side runs on
> Win/Mac/Linux and the mobile side runs on Android. Sending money from the
> desktop triggers a push notification to the mobile side, which presents the
> transaction for confirmation. Additionally the desktop wallet has a variety
> of other features like OneName integration. It's currently in alpha, but I
> suspect it will be quite popular once released due to its focus on UI and
> the simple mobile security model. I've tried it out and it worked fine.
>
> https://www.bitcoinauthenticator.org/
> https://github.com/cpacia/BitcoinAuthenticator/commits/master (mobile)
> https://github.com/negedzuregal/BitcoinAuthWallet (desktop)
>
> Bitcoin Authenticator uses P2SH/CHECKMULTISIG to provide the 2-factor
> functionality. However, this has various downsides that are well known:
> less support for the address type and larger transactions that waste block
> chain space + result in higher fees.
>
> To solve this problem Christopher Mann and Daniel Loebenberger from Uni
> Bonn have ported the efficient DSA 2-of-2 signing protocol by MacKenzie and
> Reiter to ECDSA, and implemented their own desktop/Android wallet app pair
> showing that it works and has good enough performance. This means that P2SH
> / CHECKMULTISIG is no longer required for the two factor auth case, and
> thus it's as cheap as using regular addresses.
>
> https://github.com/ChristopherMann/2FactorWallet
> https://eprint.iacr.org/2014/629.pdf
>
> Their protocol uses an interesting combination of ECDSA, Paillier
> homomorphic encryption and some zero knowledge proofs to build a working
> solution for the 2-of-2 case only. Their app bootstraps from a QR code that
> includes a TLS public key and IP address of the desktop: the mobile app
> then connects to it directly, renders the transaction and performs the
> protocol when the user confirms. The protocol is online, so both devices
> must be physically present.
>
> Their code is liberally licensed and looks easy to integrate with Alon and
> Chris' more user focused work, as both projects are built with Android and
> the latest bitcoinj. If someone is interested, merging Christopher/Daniel's
> code into the bitcoinj multisig framework would be a useful project, and
> would make it easier for wallet devs to benefit from this work. I can write
> a design doc to follow if needed.
>
> Currently, neither of these projects implement support for BIP70, so the
> screen you see when signing the transaction is hardly user friendly or
> secure: you just have to trust that the destination address you're paying
> to isn't tampered with. Support for sending a full payment request between
> devices is the clear next step once these wallets have obtained a
> reasonable user base and are stable.
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a113d1c7065d52d05075d4f55
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Thanks Mike I'll have to read that threshold signature p=
aper. </p>
<p dir=3D"ltr">I am familiar with the Princeton threshold signature but I w=
as under the impression a single key needed to be generated on a single dev=
ice then split and distributed.</p>
<p dir=3D"ltr">Does this scheme work the same way? </p>
<p dir=3D"ltr">I would have concerns about generating a key on a compromise=
d computer. </p>
<div class=3D"gmail_quote">On Nov 8, 2014 11:05 AM, "Mike Hearn" =
<<a href=3D"mailto:mike@plan99.net">mike@plan99.net</a>> wrote:<br ty=
pe=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Here is =
a summary of current developments in the space of decentralised 2-factor Bi=
tcoin wallets. I figured some people here might find it interesting.<div><b=
r></div><div>There has been very nice progress in the last month or two. De=
centralised 2FA wallets run on a desktop/laptop and have a (currently alway=
s Android) smartphone app to go with them. Compromise of the wallet require=
s compromise of both devices.<div><br></div><div>Alon Muroch and Chris Paci=
a have made huge progress on "Bitcoin Authenticator", their (HD) =
wallet app. The desktop side runs on Win/Mac/Linux and the mobile side runs=
on Android. Sending money from the desktop triggers a push notification to=
the mobile side, which presents the transaction for confirmation. Addition=
ally the desktop wallet has a variety of other features like OneName integr=
ation. It's currently in alpha, but I suspect it will be quite popular =
once released due to its focus on UI and the simple mobile security model. =
I've tried it out and it worked fine.</div><div><br></div><div><a href=
=3D"https://www.bitcoinauthenticator.org/" target=3D"_blank">https://www.bi=
tcoinauthenticator.org/</a></div><div><a href=3D"https://github.com/cpacia/=
BitcoinAuthenticator/commits/master" target=3D"_blank">https://github.com/c=
pacia/BitcoinAuthenticator/commits/master</a> =C2=A0 =C2=A0(mobile)<br></di=
v><div><a href=3D"https://github.com/negedzuregal/BitcoinAuthWallet" target=
=3D"_blank">https://github.com/negedzuregal/BitcoinAuthWallet</a> =C2=A0 (d=
esktop)<br></div><div><br></div><div>Bitcoin Authenticator uses P2SH/CHECKM=
ULTISIG to provide the 2-factor functionality. However, this has various do=
wnsides that are well known: =C2=A0less support for the address type and la=
rger transactions that waste block chain space + result in higher fees.</di=
v><div><br></div><div>To solve this problem Christopher Mann and Daniel Loe=
benberger from Uni Bonn have ported the efficient DSA 2-of-2 signing protoc=
ol by MacKenzie and Reiter to ECDSA, and implemented their own desktop/Andr=
oid wallet app pair showing that it works and has good enough performance. =
This means that P2SH / CHECKMULTISIG is no longer required for the two fact=
or auth case, and thus it's as cheap as using regular addresses.</div><=
div><br></div><div><a href=3D"https://github.com/ChristopherMann/2FactorWal=
let" target=3D"_blank">https://github.com/ChristopherMann/2FactorWallet</a>=
<br></div></div><div><a href=3D"https://eprint.iacr.org/2014/629.pdf" targe=
t=3D"_blank">https://eprint.iacr.org/2014/629.pdf</a><br></div><div><br></d=
iv><div>Their protocol uses an interesting combination of ECDSA, Paillier h=
omomorphic encryption and some zero knowledge proofs to build a working sol=
ution for the 2-of-2 case only. Their app bootstraps from a QR code that in=
cludes a TLS public key and IP address of the desktop: the mobile app then =
connects to it directly, renders the transaction and performs the protocol =
when the user confirms. The protocol is online, so both devices must be phy=
sically present.</div><div><br></div><div>Their code is liberally licensed =
and looks easy to integrate with Alon and Chris' more user focused work=
, as both projects are built with Android and the latest bitcoinj. If someo=
ne is interested, merging Christopher/Daniel's code into the bitcoinj m=
ultisig framework would be a useful project, and would make it easier for w=
allet devs to benefit from this work. I can write a design doc to follow if=
needed.</div><div><br></div><div>Currently, neither of these projects impl=
ement support for BIP70, so the screen you see when signing the transaction=
is hardly user friendly or secure: you just have to trust that the destina=
tion address you're paying to isn't tampered with. Support for send=
ing a full payment request between devices is the clear next step once thes=
e wallets have obtained a reasonable user base and are stable.</div><div><b=
r></div><div><br></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div>
--001a113d1c7065d52d05075d4f55--
|
