public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@bitpay•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Update on mobile 2-factor wallets
Date: Sat, 8 Nov 2014 17:21:02 +0100	[thread overview]
Message-ID: <CAJHLa0Or1RW0k+FP+hu-GTv+DdZZ=P=ptO1qr=qAHVMQok2w1Q@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3Pk3O3uFJtDkO9BfVogbaiWt1SmMrP02fRBpt3TtMrtg@mail.gmail.com>

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/



  reply	other threads:[~2014-11-08 16:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-08 16:04 Mike Hearn
2014-11-08 16:21 ` Jeff Garzik [this message]
2014-11-08 16:37   ` Mike Hearn
2014-11-08 18:43 ` Chris Pacia
2014-11-08 19:36   ` Mike Hearn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJHLa0Or1RW0k+FP+hu-GTv+DdZZ=P=ptO1qr=qAHVMQok2w1Q@mail.gmail.com' \
    --to=jgarzik@bitpay$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=mike@plan99$(echo .)net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox