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 <jgarzik@bitpay.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CANEZrP3Pk3O3uFJtDkO9BfVogbaiWt1SmMrP02fRBpt3TtMrtg@mail.gmail.com>
References: <CANEZrP3Pk3O3uFJtDkO9BfVogbaiWt1SmMrP02fRBpt3TtMrtg@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Sat, 8 Nov 2014 17:21:02 +0100
Message-ID: <CAJHLa0Or1RW0k+FP+hu-GTv+DdZZ=P=ptO1qr=qAHVMQok2w1Q@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
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 <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 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 <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
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/