From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xn8VU-0002kX-Gx for bitcoin-development@lists.sourceforge.net; Sat, 08 Nov 2014 16:04:56 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.44 as permitted sender) client-ip=209.85.215.44; envelope-from=mh.in.england@gmail.com; helo=mail-la0-f44.google.com; Received: from mail-la0-f44.google.com ([209.85.215.44]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xn8VS-0005ly-My for bitcoin-development@lists.sourceforge.net; Sat, 08 Nov 2014 16:04:56 +0000 Received: by mail-la0-f44.google.com with SMTP id gf13so5915087lab.17 for ; Sat, 08 Nov 2014 08:04:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.27.2 with SMTP id p2mr8889956lag.19.1415462688141; Sat, 08 Nov 2014 08:04:48 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.25.91.147 with HTTP; Sat, 8 Nov 2014 08:04:48 -0800 (PST) Date: Sat, 8 Nov 2014 17:04:48 +0100 X-Google-Sender-Auth: gwxf4-CtttqyGRttR6QB3h0l5oU Message-ID: From: Mike Hearn To: Bitcoin Dev Content-Type: multipart/alternative; boundary=089e0158c200b838d005075b16d2 X-Spam-Score: -0.2 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.3 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) [URIs: github.com] 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1Xn8VS-0005ly-My Subject: [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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 16:04:56 -0000 --089e0158c200b838d005075b16d2 Content-Type: text/plain; charset=UTF-8 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. --089e0158c200b838d005075b16d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here is a summary of current developments in the space of = decentralised 2-factor Bitcoin wallets. I figured some people here might fi= nd it interesting.

There has been very nice progress in = the last month or two. Decentralised 2FA wallets run on a desktop/laptop an= d have a (currently always Android) smartphone app to go with them. Comprom= ise of the wallet requires compromise of both devices.

A= lon Muroch and Chris Pacia have made huge progress on "Bitcoin Authent= icator", their (HD) wallet app. The desktop side runs on Win/Mac/Linux= and the mobile side runs on Android. Sending money from the desktop trigge= rs a push notification to the mobile side, which presents the transaction f= or confirmation. Additionally the desktop wallet has a variety of other fea= tures 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 simpl= e mobile security model. I've tried it out and it worked fine.


Bitcoin Authenticator uses P2SH/CHECKMULTISIG to provide the 2-facto= r functionality. However, this has various downsides that are well known: = =C2=A0less support for the address type and larger transactions that waste = block chain space + result in higher fees.

To solv= e 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 t= hat it works and has good enough performance. This means that P2SH / CHECKM= ULTISIG is no longer required for the two factor auth case, and thus it'= ;s as cheap as using regular addresses.


Their protocol uses an interesting combination of ECDSA, = Paillier homomorphic encryption and some zero knowledge proofs to build a w= orking solution for the 2-of-2 case only. Their app bootstraps from a QR co= de 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 m= ust be physically present.

Their code is liberally= licensed and looks easy to integrate with Alon and Chris' more user fo= cused 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 ea= sier for wallet devs to benefit from this work. I can write a design doc to= follow if needed.

Currently, neither of these pro= jects implement support for BIP70, so the screen you see when signing the t= ransaction is hardly user friendly or secure: you just have to trust that t= he destination address you're paying to isn't tampered with. Suppor= t 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.


--089e0158c200b838d005075b16d2--