Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil <eric@voskuil.org>]

[-- 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 --]