{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-02-23\n📝 Original message:\u003e\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\nYou're right that just sending the session key is simpler. I originally\nsuggested doing ECDHE to set up an encrypted channel for the following\nreasons:\n\n   1. URIs are put in QR codes more often than NFC tags. QR codes have\n   limited space. The more stuff you pack into them, the slower and flakier\n   the scanning process becomes.\n\n   For normal wallets, doing ECDH over secp256k1 to derive a session key\n   means we can reuse the address that was put in the URI already for\n   pre-BIP70 wallets, thus we don't have to expand the URI at all except\n   perhaps to flag that crypted Bluetooth connections are supported. Win!\n\n   2. If the wallet is a watching wallet, this won't work and in that case\n   you would need to put a separate key into the URI. However, this key is\n   ephemeral and does not need to be very strong. So we can generate a regular\n   secp256k1 key and then put say 5-8 prefix bytes into the URI as a new\n   parameter. The public key can then be provided in full in the clear over\n   the Bluetooth connection and the session key derived. If we put the session\n   key into the URI in full, then we could not use this trick. Win!\n\n   3. It's quite common in low tech scenarios like little coffee shops to\n   just print a QR code and put it in the menu, or sticky tape it to the back\n   wall of the shop.\n\n   In these cases, it's possible that the device is actually hanging around\n   in the shop somewhere but having the QR code somewhere larger and more\n   accessible than the shop devices screen is highly convenient. However it\n   means the data is entirely static.\n\n   Putting/reusing an identity key from the URI means the session keys are\n   always unique and known only to both devices, even though the bootstrap\n   data is public.\n\n   4. Doing ECDHE to derive the keys means we can derive a MAC key as well\n   as an AES key. Otherwise you have the issue of exchanging both, which again\n   uses up valuable bootstrap space.\n\nSo for a small increase in session setup complexity we potentially avoid\ntroubling problems down the line where people the same functionality from\nNFC and QR code based bootstrap, but we can't provide it.\n\nThese discussions keep coming up. I think the next step is for someone to\nupgrade Andreas' wallet to support encrypted connections and the TBIPs, to\nsee what happens.\n\nRe: the h= parameter. I only objected to requiring this when the payment\nrequest is also signed. It adds complexity, uses space, and the rationale\nwas \"the PKI can't be trusted\" even though it's been used to protect credit\ncard payments for 20 years without any issues. In the case of unsigned\npayment requests, sure ... but with a proper implementation of an encrypted\nBluetooth channel it'd be unnecessary as the channel establishment process\nwould guarantee authenticity anyway.\n\nBut don't let me hold you guys back! I'd rather see something that works\nthan an endless debate about the perfect arrangement of hashes and URI\nparameters :)\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/dac2bed5/attachment.html\u003e"}