On 02/05/2015 02:08 PM, Paul Puey wrote: > Although not perfect, and it may require visual/verbal verification, > I don't see what the trust issue is.
I agree that with manual verification between the parties the worst problem becomes DOS, which is certainly not catastrophic. But the objective is to the extent possible improve upon the cumbersome process of QR code, NFC signal, or textual address scanning. Given that there would be no way to know you are under attack, with the exception of manual confirmation, it would seem unwise to ever rely on the automation. If the automation cannot be relied upon, it may actually make matters worse. People would either take their chances by relying on it or go through a more complex process. In terms of the difficulty of an attack, it's important to recognize that all attacks (DOS, privacy, integrity) in this scenario can be fully-automated and executed over the air by a black box at some distance: * DOS is possible by rebroadcasting a similar request. * Privacy is compromised by monitoring for payment requests and correlating them to location and potentially images of parties. * Integrity is compromised by either: (1) Rebroadcasting a similar transaction with a bogus address but with the same leading characters; can't be spent but you lose your money. (2) Rebroadcasting with a valid address that doesn't match the leading characters, in the expectation that the user doesn't check manually. Regarding possible mitigation via BIP-70: A BIP-70 signed payment request in the initial broadcast can resolve the integrity issues, but because of the public nature of the broadcast coupled with strong public identity, the privacy compromise is much worse. Now transactions are cryptographically tainted. This is also the problem with BIP-70 over the web. TLS and other security precautions aside, an interloper on the communication, desktop, datacenter, etc., can capture payment requests and strongly correlate transactions to identities in an automated manner. The payment request must be kept private between the parties, and that's hard to do. So the initial broadcast needs privacy, but then of course it cannot be a broadcast - it need to be a narrow cast. That brings us back to proximity-based establishment. I think that you could get away with this for a while, simply because of the narrow fields we are working in presently. But in a bitcoin world it would be very problematic. For this reason I wouldn't want to encourage standardization on this approach. e On 02/05/2015 02:10 PM, Eric Voskuil wrote: > A MITM can receive the initial broadcast and then spoof it by jamming > the original. You then only see one. > > e > > On Feb 5, 2015, at 2:07 PM, Paul Puey <p...@airbitz.co > <mailto:p...@airbitz.co>> wrote: > >> So if you picked up the BLE broadcast request. All you know is that >> *someone* within 100m is requesting bitcoin at a certain address. Not >> necessarily who. The *name* is both optional, and possibly just a >> *handle* of the user. If I'm sitting 5 ft away from someone at dinner >> and wanted to pay them via BLE, I might see "Monkey Dude" on my list >> and simply ask him "is that you?" If so, I send it. If there are two >> "Monkey Dude's" Then I have to bother with the address prefix, but not >> otherwise. >> >> On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil <e...@voskuil.org >> <mailto:e...@voskuil.org>> wrote: >> >> BLE has an advertised range of over 100m. >> >> http://www.bluetooth.com/Pages/low-energy-tech-info.aspx >> >> In the case of mass surveillance that range could most likely be >> extended dramatically by the reviewer. I've seen WiFi ranges of >> over a mile with a strong (not FCC approved) receiver. >> >> WiFi hotspots don't have strong identity or a guaranteed position, >> so they can't be trusted for location. >> >> e >> >> On Feb 5, 2015, at 1:36 PM, Mike Hearn <m...@plan99.net >> <mailto:m...@plan99.net>> wrote: >> >>> This sounds horrible. You could basically monitor anyone with >>> a wallet in a highly populated area and track them super >>> easily by doing facial recognition. >>> >>> >>> We're talking about BLE, still? The radio tech that runs in the >>> so called "junk bands" because propagation is so poor? >>> >>> My watch loses its connection to my phone if I just put it down >>> and walk around my apartment. I'm all for reasonable paranoia, >>> but Bluetooth isn't going to be enabling mass surveillance any >>> time soon. It barely goes through air, let alone walls. >>> >>> Anyway, whatever. I'm just bouncing around ideas for faster user >>> interfaces. You could always switch it off or set it to be >>> triggered by the presence of particular wifi hotspots, if you >>> don't mind an initial bit of setup. >>> >>> Back on topic - the debate is interesting, but I think to get >>> this to the stage of being a BIP we'd need at least another >>> wallet to implement it? Then I guess a BIP would be useful >>> regardless of the design issues. The prefix matching still feels >>> flaky to me but it's hard to know if you could really swipe >>> payments out of the air in practice, without actually trying it. >>> >>> >>
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
