rich1.0npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3chttps://nostr.ae/npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cnjumphttps://nostr.ae📅 Original date posted:2015-02-23 📝 Original message: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 :) > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/ec6fbecf/attachment.sig>