{"type":"rich","version":"1.0","author_name":"npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3c","author_url":"https://nostr.ae/npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3c","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-02-23\n📝 Original message:Mike,\n\nBefore addressing other issues I could use some clarification on your\nintent.\n\nIn one statement you refer to derivation of a session key from a bitcoin\naddress (passed via NFC):\n\n\u003e doing ECDH over secp256k1 to derive a session key means we can reuse\n\u003e the address that was put in the URI already for pre-BIP70 wallets\n\nIn another statement you refer to derivation of a session key from a\npublic key (passed via  BT):\n\n\u003e The public key can then be provided in full in the clear over the\n\u003e Bluetooth connection and the session key derived.\n\nI don't see how you propose to treat the bitcoin address as a secp256k1\npublic key, or do you mean something else?\n\ne\n\nOn 02/23/2015 02:58 AM, Mike Hearn wrote:\n\u003e     DHKE will not improve the situation. Either we use a simple method to\n\u003e     transfer a session key or a complex method.\n\u003e \n\u003e You're right that just sending the session key is simpler. I originally\n\u003e suggested doing ECDHE to set up an encrypted channel for the following\n\u003e reasons:\n\u003e \n\u003e  1. URIs are put in QR codes more often than NFC tags. QR codes have\n\u003e     limited space. The more stuff you pack into them, the slower and\n\u003e     flakier the scanning process becomes.\n\u003e \n\u003e     For normal wallets, doing ECDH over secp256k1 to derive a session\n\u003e     key means we can reuse the address that was put in the URI already\n\u003e     for pre-BIP70 wallets, thus we don't have to expand the URI at all\n\u003e     except perhaps to flag that crypted Bluetooth connections are\n\u003e     supported. Win!\n\u003e \n\u003e  2. If the wallet is a watching wallet, this won't work and in that case\n\u003e     you would need to put a separate key into the URI. However, this key\n\u003e     is ephemeral and does not need to be very strong. So we can generate\n\u003e     a regular secp256k1 key and then put say 5-8 prefix bytes into the\n\u003e     URI as a new parameter. The public key can then be provided in full\n\u003e     in the clear over the Bluetooth connection and the session key\n\u003e     derived. If we put the session key into the URI in full, then we\n\u003e     could not use this trick. Win!\n\u003e \n\u003e  3. It's quite common in low tech scenarios like little coffee shops to\n\u003e     just print a QR code and put it in the menu, or sticky tape it to\n\u003e     the back wall of the shop.\n\u003e \n\u003e     In these cases, it's possible that the device is actually hanging\n\u003e     around in the shop somewhere but having the QR code somewhere larger\n\u003e     and more accessible than the shop devices screen is highly\n\u003e     convenient. However it means the data is entirely static.\n\u003e \n\u003e     Putting/reusing an identity key from the URI means the session keys\n\u003e     are always unique and known only to both devices, even though the\n\u003e     bootstrap data is public.\n\u003e \n\u003e  4. Doing ECDHE to derive the keys means we can derive a MAC key as well\n\u003e     as an AES key. Otherwise you have the issue of exchanging both,\n\u003e     which again uses up valuable bootstrap space.\n\u003e \n\u003e So for a small increase in session setup complexity we potentially avoid\n\u003e troubling problems down the line where people the same functionality\n\u003e from NFC and QR code based bootstrap, but we can't provide it.\n\u003e \n\u003e These discussions keep coming up. I think the next step is for someone\n\u003e to upgrade Andreas' wallet to support encrypted connections and the\n\u003e TBIPs, to see what happens.\n\u003e \n\u003e Re: the h= parameter. I only objected to requiring this when the payment\n\u003e request is also signed. It adds complexity, uses space, and the\n\u003e rationale was \"the PKI can't be trusted\" even though it's been used to\n\u003e protect credit card payments for 20 years without any issues. In the\n\u003e case of unsigned payment requests, sure ... but with a proper\n\u003e implementation of an encrypted Bluetooth channel it'd be unnecessary as\n\u003e the channel establishment process would guarantee authenticity anyway.\n\u003e \n\u003e But don't let me hold you guys back! I'd rather see something that works\n\u003e than an endless debate about the perfect arrangement of hashes and URI\n\u003e parameters :)\n\u003e \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 473 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/ec6fbecf/attachment.sig\u003e"}