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 ) 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 ; 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: References: Date: Sat, 8 Nov 2014 13:43:48 -0500 Message-ID: From: Chris Pacia To: Mike Hearn 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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

Thanks Mike I'll have to read that threshold signature p= aper.

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.

Does this scheme work the same way?

I would have concerns about generating a key on a compromise= d 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 Bi= tcoin wallets. I figured some people here might find it interesting.
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.

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.

https://github.com/c= pacia/BitcoinAuthenticator/commits/master =C2=A0 =C2=A0(mobile)

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.

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>

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.

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.

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.


-----------------------------------------------------------------------= -------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a113d1c7065d52d05075d4f55--