* [Bitcoin-development] Update on mobile 2-factor wallets
@ 2014-11-08 16:04 Mike Hearn
2014-11-08 16:21 ` Jeff Garzik
2014-11-08 18:43 ` Chris Pacia
0 siblings, 2 replies; 5+ messages in thread
From: Mike Hearn @ 2014-11-08 16:04 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3175 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 3837 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Update on mobile 2-factor wallets
2014-11-08 16:04 [Bitcoin-development] Update on mobile 2-factor wallets Mike Hearn
@ 2014-11-08 16:21 ` Jeff Garzik
2014-11-08 16:37 ` Mike Hearn
2014-11-08 18:43 ` Chris Pacia
1 sibling, 1 reply; 5+ messages in thread
From: Jeff Garzik @ 2014-11-08 16:21 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Update on mobile 2-factor wallets
2014-11-08 16:21 ` Jeff Garzik
@ 2014-11-08 16:37 ` Mike Hearn
0 siblings, 0 replies; 5+ messages in thread
From: Mike Hearn @ 2014-11-08 16:37 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4951 bytes --]
Yes. I think one of the next things we need is a library that produces nice
and attractive PDFs of "wallet certificates" so it's easy to print out a
paper backup.
But the whole field of secure key escrow needs more research. Banking gives
people the very nice property that you can lose literally everything except
your face and still retain access to your money, so people feel very safe
with that. Matching that experience doesn't seem possible at the moment, so
being your own bank will continue to seem much riskier than just using a
real one.
On 8 Nov 2014 17:21, "Jeff Garzik" <jgarzik@bitpay•com> wrote:
> 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/
>
[-- Attachment #2: Type: text/html, Size: 6367 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Update on mobile 2-factor wallets
2014-11-08 16:04 [Bitcoin-development] Update on mobile 2-factor wallets Mike Hearn
2014-11-08 16:21 ` Jeff Garzik
@ 2014-11-08 18:43 ` Chris Pacia
2014-11-08 19:36 ` Mike Hearn
1 sibling, 1 reply; 5+ messages in thread
From: Chris Pacia @ 2014-11-08 18:43 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3977 bytes --]
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" <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
>
>
[-- Attachment #2: Type: text/html, Size: 5081 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-11-08 19:36 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-08 16:04 [Bitcoin-development] Update on mobile 2-factor wallets Mike Hearn
2014-11-08 16:21 ` Jeff Garzik
2014-11-08 16:37 ` Mike Hearn
2014-11-08 18:43 ` Chris Pacia
2014-11-08 19:36 ` Mike Hearn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox