From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xn8lU-0007sM-No for bitcoin-development@lists.sourceforge.net; Sat, 08 Nov 2014 16:21:28 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.223.170 as permitted sender) client-ip=209.85.223.170; envelope-from=jgarzik@bitpay.com; helo=mail-ie0-f170.google.com; Received: from mail-ie0-f170.google.com ([209.85.223.170]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xn8lT-0003dD-Gz for bitcoin-development@lists.sourceforge.net; Sat, 08 Nov 2014 16:21:28 +0000 Received: by mail-ie0-f170.google.com with SMTP id tp5so7060069ieb.15 for ; Sat, 08 Nov 2014 08:21:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MyyFrMfuXJ/NSdeMLZRbRpAjNg7j0Me32l+8AcV4vgk=; b=ggORkJnVy/r6qh6DuK8A2pdvJ0nWsWp4VrejL3odA52TaLZCOog5VX8G8hRmAfr1GO NkDR+opB2N5CWy4GRUDchjqiIp9eco2qNHCeID/vJCglY4DUAfRITt7VR0363+SPYPe9 zSemG20jd55I43ZF2sisGsPKanzBlmb59mp5RDCmpZIvS6jv26WRocNudg5ozsab7K1H gyKrFddOML2kxgtb47RKXjbSgHJNetpWIY/8uza3QUJKGQ5Zmy3JJc9qlH4KVc0582/7 dXKknhlaBRLuw9Bm7+dkqMgP3s6QYAeA56v4SLlJwHGcSVQnSDTvzX4qnQ+9zxEzwyVj TJ6w== X-Gm-Message-State: ALoCoQkVTMtiWQ78eCtX3eK/wmfvVXjwQemsfNXYPlg1zQkj14IzPKLOCuPCbvg14qyP0tN2hGKl X-Received: by 10.50.80.18 with SMTP id n18mr2739828igx.22.1415463682132; Sat, 08 Nov 2014 08:21:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.136.164 with HTTP; Sat, 8 Nov 2014 08:21:02 -0800 (PST) In-Reply-To: References: From: Jeff Garzik Date: Sat, 8 Nov 2014 17:21:02 +0100 Message-ID: To: Mike Hearn Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.3 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.3 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) [URIs: github.com] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -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: 1Xn8lT-0003dD-Gz 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 16:21:28 -0000 Overall, super duper awesome. :) Tweeted this post. I do have a concern about 2-of-2 arrangements. To me, this screams "twice as fragile" if not done properly; and I've seen a few naive implementations in the field that seemed quite fragile. 2FA/2-of-2 does solve the common problem of single device compromise. It also makes funds unspendable if -either- device's keys become lost. On Sat, Nov 8, 2014 at 5:04 PM, 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 > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/