From: Mike Hearn <mike@plan99•net>
To: Eric Voskuil <eric@voskuil•org>
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 11:58:11 +0100 [thread overview]
Message-ID: <CANEZrP0XYfnarvN5H_NeOGyO8RLBSGyGxv7M63MSrAd_HXj1OQ@mail.gmail.com> (raw)
In-Reply-To: <54EAFC1C.9080502@voskuil.org>
[-- Attachment #1: Type: text/plain, Size: 3090 bytes --]
>
> 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: Type: text/html, Size: 3465 bytes --]
next prev parent reply other threads:[~2015-02-23 10:58 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-22 19:08 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 [this message]
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
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=CANEZrP0XYfnarvN5H_NeOGyO8RLBSGyGxv7M63MSrAd_HXj1OQ@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=andreas@schildbach$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=eric@voskuil$(echo .)org \
/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