diff options
| author | Chris Pacia <ctpacia@gmail.com> | 2014-11-08 13:43:48 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-11-08 18:43:55 +0000 |
| commit | d96c3ff0b0cb5fc69de0477ad255ed8c4a1f0a2c (patch) | |
| tree | c7f58b989208145b9bb3656a78f44e902af724d0 | |
| parent | b0672b1cf8ef959256f64cab268a41cca61495fd (diff) | |
| download | pi-bitcoindev-d96c3ff0b0cb5fc69de0477ad255ed8c4a1f0a2c.tar.gz pi-bitcoindev-d96c3ff0b0cb5fc69de0477ad255ed8c4a1f0a2c.zip | |
Re: [Bitcoin-development] Update on mobile 2-factor wallets
| -rw-r--r-- | 6e/3266ec90c6526cefeb1948e689601df6acac2b | 228 |
1 files changed, 228 insertions, 0 deletions
diff --git a/6e/3266ec90c6526cefeb1948e689601df6acac2b b/6e/3266ec90c6526cefeb1948e689601df6acac2b new file mode 100644 index 000000000..28d4cd5a4 --- /dev/null +++ b/6e/3266ec90c6526cefeb1948e689601df6acac2b @@ -0,0 +1,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-- + + |