public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil.org>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Date: Mon, 23 Feb 2015 15:00:29 -0800	[thread overview]
Message-ID: <54EBB10D.8020502@voskuil.org> (raw)
In-Reply-To: <CANEZrP0XYfnarvN5H_NeOGyO8RLBSGyGxv7M63MSrAd_HXj1OQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4035 bytes --]

Mike,

Before addressing other issues I could use some clarification on your
intent.

In one statement you refer to derivation of a session key from a bitcoin
address (passed via NFC):

> doing ECDH over secp256k1 to derive a session key means we can reuse
> the address that was put in the URI already for pre-BIP70 wallets

In another statement you refer to derivation of a session key from a
public key (passed via  BT):

> The public key can then be provided in full in the clear over the
> Bluetooth connection and the session key derived.

I don't see how you propose to treat the bitcoin address as a secp256k1
public key, or do you mean something else?

e

On 02/23/2015 02:58 AM, Mike Hearn wrote:
>     DHKE will not improve the situation. Either we use a simple method to
>     transfer a session key or a complex method.
> 
> You're right that just sending the session key is simpler. I originally
> suggested doing ECDHE to set up an encrypted channel for the following
> reasons:
> 
>  1. URIs are put in QR codes more often than NFC tags. QR codes have
>     limited space. The more stuff you pack into them, the slower and
>     flakier the scanning process becomes.
> 
>     For normal wallets, doing ECDH over secp256k1 to derive a session
>     key means we can reuse the address that was put in the URI already
>     for pre-BIP70 wallets, thus we don't have to expand the URI at all
>     except perhaps to flag that crypted Bluetooth connections are
>     supported. Win!
> 
>  2. If the wallet is a watching wallet, this won't work and in that case
>     you would need to put a separate key into the URI. However, this key
>     is ephemeral and does not need to be very strong. So we can generate
>     a regular secp256k1 key and then put say 5-8 prefix bytes into the
>     URI as a new parameter. The public key can then be provided in full
>     in the clear over the Bluetooth connection and the session key
>     derived. If we put the session key into the URI in full, then we
>     could not use this trick. Win!
> 
>  3. It's quite common in low tech scenarios like little coffee shops to
>     just print a QR code and put it in the menu, or sticky tape it to
>     the back wall of the shop.
> 
>     In these cases, it's possible that the device is actually hanging
>     around in the shop somewhere but having the QR code somewhere larger
>     and more accessible than the shop devices screen is highly
>     convenient. However it means the data is entirely static.
> 
>     Putting/reusing an identity key from the URI means the session keys
>     are always unique and known only to both devices, even though the
>     bootstrap data is public.
> 
>  4. Doing ECDHE to derive the keys means we can derive a MAC key as well
>     as an AES key. Otherwise you have the issue of exchanging both,
>     which again uses up valuable bootstrap space.
> 
> So for a small increase in session setup complexity we potentially avoid
> troubling problems down the line where people the same functionality
> from NFC and QR code based bootstrap, but we can't provide it.
> 
> These discussions keep coming up. I think the next step is for someone
> to upgrade Andreas' wallet to support encrypted connections and the
> TBIPs, to see what happens.
> 
> Re: the h= parameter. I only objected to requiring this when the payment
> request is also signed. It adds complexity, uses space, and the
> rationale was "the PKI can't be trusted" even though it's been used to
> protect credit card payments for 20 years without any issues. In the
> case of unsigned payment requests, sure ... but with a proper
> implementation of an encrypted Bluetooth channel it'd be unnecessary as
> the channel establishment process would guarantee authenticity anyway.
> 
> But don't let me hold you guys back! I'd rather see something that works
> than an endless debate about the perfect arrangement of hashes and URI
> parameters :)
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  parent reply	other threads:[~2015-02-23 23:01 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-22 19:08 [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback Jan Vornberger
2015-02-22 22:37 ` Andy Schroder
2015-02-22 23:06   ` Eric Voskuil
2015-02-22 23:32     ` Andy Schroder
2015-02-23  0:05       ` Eric Voskuil
2015-02-23  1:02       ` Andreas Schildbach
2015-02-23  7:36         ` Andy Schroder
2015-02-23  9:13           ` Natanael
2015-02-23  9:40           ` Eric Voskuil
2015-02-24  2:55             ` Eric Voskuil
2015-02-24  5:53               ` Andy Schroder
2015-02-24 11:28                 ` Eric Voskuil
2015-02-24 19:49                   ` Andy Schroder
2015-02-24 22:14                     ` Eric Voskuil
2015-02-24 22:50                       ` Andy Schroder
2015-02-25  2:09                         ` Eric Voskuil
2015-02-28  9:46                           ` Andy Schroder
2015-02-23  9:49           ` Andreas Schildbach
2015-02-23 10:08             ` Eric Voskuil
2015-02-23 10:58               ` Mike Hearn
2015-02-23 11:58                 ` Andreas Schildbach
2015-02-23 12:18                   ` Mike Hearn
2015-02-23 12:30                     ` Andreas Schildbach
2015-02-23 23:00                 ` Eric Voskuil [this message]
2015-02-23 23:11                   ` Mike Hearn
2015-02-24  0:10                     ` Eric Voskuil
2015-02-24 10:41                       ` Mike Hearn
2015-02-26 12:30                         ` Andreas Schildbach
2015-03-03  0:54                           ` Eric Voskuil
2015-02-23  0:58   ` Andreas Schildbach
2015-02-23 15:09   ` Jan Vornberger
2015-02-23 16:59     ` Mike Hearn
2015-02-23 19:56       ` Jan Vornberger
2015-02-23 20:31         ` Mike Hearn
2015-02-24  6:14     ` Andy Schroder
2015-02-24 15:41       ` Jan Vornberger
2015-02-26 12:37     ` Andreas Schildbach
2015-02-22 22:39 ` Eric Voskuil
2015-02-22 22:48   ` Eric Voskuil
2015-02-22 23:35     ` Andy Schroder
2015-02-23  0:46       ` Eric Voskuil
2015-02-23  1:05   ` Andreas Schildbach
2015-02-23  1:55     ` Aaron Voisine
2015-02-23  0:48 ` Andreas Schildbach
     [not found] <54ED2F34.8090704@voskuil.org>
     [not found] ` <54ED3150.4020800@AndySchroder.com>
     [not found]   ` <54ED7D8B.5070903@schildbach.de>
2015-02-25  9:20     ` Eric Voskuil

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=54EBB10D.8020502@voskuil.org \
    --to=eric@voskuil.org \
    --cc=andreas@schildbach.de \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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