Re: [tor-dev] Future Onion Addresses and Human Factors
On Sun, 2015-08-09 at 07:26 +, Jeremy Rand wrote: Isn't the 51% attack down to a 20ish% attack now? The estimate I did was based on Namecoin hashrate, not Bitcoin hashrate. I assume that's the distinction you're referring to, though you're not really making it clear. No. I haven't kept up to date on blockchain technologies as they never looked particularly great to me, but.. There was a succession of research results that lowers the 51% attack on btcoin into the 30s % range and eventually into the 20s % range. I donno if OnionNS is susceptible to these attacks, as it's threat model is slightly different. I think you will find that a number of users are unlikely to exclusively use bookmarks and not use web links. There is no need for a domain on links within a single site. It's true that cross site links are common enough that fishing attacks can trick users into typing their password into a facebookfakeblah.onion url. Jeff signature.asc Description: This is a digitally signed message part ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Future Onion Addresses and Human Factors
On Aug 9, 2015, at 12:36 PM, Ben Laurie b...@links.org wrote: Can I make my usual radical suggestion? By all means discuss, but once you've finished deciding what you think is best for humans, please actually test your theory. On humans (and that means, not CS students and not Mechanical Turk). Nicely volunteered, Ben! :-) /me wonders how much ux-testing the “dotted quad” received… -a :-) — Alec Muffett Security Infrastructure Facebook Engineering London signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Future Onion Addresses and Human Factors
On Sat, 8 Aug 2015 at 13:12 Alec Muffett al...@fb.com wrote: Hence this email, in the hope of kicking off a discussion between people who care about human factors. :-) Can I make my usual radical suggestion? By all means discuss, but once you've finished deciding what you think is best for humans, please actually test your theory. On humans (and that means, not CS students and not Mechanical Turk). ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Future Onion Addresses and Human Factors
On Sun, 9 Aug 2015 at 13:29 Alec Muffett al...@fb.com wrote: On Aug 9, 2015, at 12:36 PM, Ben Laurie b...@links.org wrote: Can I make my usual radical suggestion? By all means discuss, but once you've finished deciding what you think is best for humans, please actually test your theory. On humans (and that means, not CS students and not Mechanical Turk). Nicely volunteered, Ben! :-) Well, I did help start an organisation for exactly this kind of thing (i.e. Simply Secure), so, given a concrete suggestion, I'll see what I can do. /me wonders how much ux-testing the “dotted quad” received… None. I'm sure the justification, had anyone asked (which I doubt) would've been that dotted quad is not for users. Which is largely true, despite the fact they're frequently forced to use it. Doubleplusnotforusers goes for IPv6. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Get Stem and zoossh to talk to each other
On Fri, Jul 31, 2015 at 10:00:27AM -0700, Damian Johnson wrote: Hi Philipp, sorry about the delay! Spread pretty thin right now. Would you mind discussing more about the use cases, and give a mockup for what this new domain specific language would look like in practice? My first thought is would such a language be useful enough to be worth investing time to learn?. I've made lots of things that flopped because they didn't serve a true need, and while a domain specific language for descriptors sounds neat I'm not sure if I'm seeing a need for it. I'm not quite sure yet myself. After talking to Karsten, a simple database might be good enough. Or simply reorganising the directory structure of archived data to efficiently find the consensuses, a given relay fingerprint shows up in. Either way, thanks for your thoughts! Ideally, zoossh should do the heavy lifting as it's implemented in a compiled language. This is assuming zoossh is dramatically faster than Stem by virtue of being compiled. I know we've discussed this before but I forget the results - with the latest tip of Stem (ie, with lazy loading) how do they compare? I'd expect time to be mostly bound by disk IO, so little to no difference. zoossh's test framework says that it takes 36364357 nanoseconds to lazily parse a consensus that is cached in memory (to eliminate the I/O bottleneck). That amounts to approximately 27 consensuses a second. I used the following simple Python script to get a similar number for Stem: with open(file_name) as consensus_file: for router in stem.descriptor.parse_file(consensus_file, 'network-status-consensus-3 1.0', document_handler = stem.descriptor.DocumentHandler.ENTRIES): pass This script manages to parse 24 consensus files in ~13 seconds, which amounts to 1.8 consensuses a second. Let me know if there's a more efficient way to do this in Stem. Cheers, Philipp ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Future Onion Addresses and Human Factors
On Sat, Aug 08, 2015 at 11:36:35AM +, Alec Muffett wrote: 1) it’s all very well to go an mine something like “facebookcorewwwi” as an onion address, but 16 characters probably already exceeds human ability for easy string comparison. I wonder if a better way forward is to focus on tools (e.g., a petname system in Tor Browser) to automate dealing with onion addresses rather than making them easier to deal with for humans. Vanity onion addresses, for example, might have done more harm than good, and should perhaps be made impractical by incorporating a key derivation function in their generation. As a result, maybe we should make it intentionally *harder* to manage raw onion addresses, just like it's hard to manage raw barcodes. Cheers, Philipp ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Future Onion Addresses and Human Factors
On Sat, Aug 8, 2015 at 9:05 AM, Roger Dingledine a...@mit.edu wrote: On Sat, Aug 08, 2015 at 11:36:35AM +, Alec Muffett wrote: 5) taking a cue from World War Two cryptography, breaking this into banks of five characters which provide the eyeball a point upon which to rest, might help: a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sd.onion agdjd-recognisable-word-kjhsdhkjdshhlsdblahblah.onion I'm a fan: https://trac.torproject.org/projects/tor/ticket/15622 Though I fear my point in the ticket about the Host: header might be a good one. Proposal 224 seems like a reasonable time to try this. Doling it with the existing hidden services would add a way to partition clients. If the hyphens are made canonical so that they're expected to occur every N characters, for N something like 5-9 [*], we could avoid the Host: issues. [*]https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Future Onion Addresses and Human Factors
I did a rough calculation about a year ago of how much it would cost to buy ASIC miners that could 51%-attack Namecoin, and it came out to just under a billion USD. Isn't the 51% attack down to a 20ish% attack now? Of course, a real-world attacker would (in my estimate) probably be more likely to try to compromise existing miners (via either technical attacks, extortion/blackmail/bribery, or legal pressure). Isn't 50ish% controlled by one organization already Is it not a particularly tight not organization or something? Isn't the real world attack that you simply isolate a namecoin user from the wider namecoin network? That's cheap for state level attackers. I'd imagine OnioNS should have a massive advantage here because Tor has pinned directory authorities, who presumably help OnioNS accurately identify honest quorum servers. An end user will be much more likely to notice when a Namecoin or OnioNS name changes, compared to when a .onion name changes. So this isn't really a clear win for .onion -- it's a tradeoff, and which is more secure depends on which end users we're talking about, and what threat model we're dealing with. This is false. Users must enter the .onion address from somewhere. If they go through a search engine, then yes the .onion address itself is hard to remember, especially if they visit many sites. Key poems address this. If however they employ bookmarks, copy from a file, etc., and roughly proposal 244 gets adopted, then an attacker must hack the user's machine, hack the server, or break a curve25519 public key. Yes, a search engine covers .onion addresses should ask users to bookmark desirable results, as opposed to revisiting the search engine, mostly for the protection of the search engine. signature.asc Description: This is a digitally signed message part ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Future Onion Addresses and Human Factors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/09/2015 06:54 AM, Jeff Burdges wrote: I did a rough calculation about a year ago of how much it would cost to buy ASIC miners that could 51%-attack Namecoin, and it came out to just under a billion USD. Isn't the 51% attack down to a 20ish% attack now? The estimate I did was based on Namecoin hashrate, not Bitcoin hashrate. I assume that's the distinction you're referring to, though you're not really making it clear. Of course, a real-world attacker would (in my estimate) probably be more likely to try to compromise existing miners (via either technical attacks, extortion/blackmail/bribery, or legal pressure). Isn't 50ish% controlled by one organization already Is it not a particularly tight not organization or something? Of Bitcoin or Namecoin? Definitely not in the case of Bitcoin (though 50% of Bitcoin hashpower was controlled by one pool, GHash.IO, a year or two ago). Pools and miners are not equivalent, because if a pool does something shady, it's easily detectable and the miners who use that pool (of which there are many) are free to switch to a different pool. F2Pool does have a majority of Namecoin hashpower at the moment, because several other Bitcoin pools aren't mining Namecoin. This is, to my knowledge, because those pools are unaware of the newer Namecoin software (Namecoin Core) and had some problems with the old Namecoin 0.3.80 code (which was deprecated many months ago in favor of Namecoin Core). We're looking at reaching out to pools that aren't mining Namecoin right now, and I certainly agree that it is not great that F2Pool has a majority. If 1 or 2 other Bitcoin pools started mining Namecoin, that would not be the case anymore. FWIW, I've seen no evidence that F2Pool is shady in any way; they've been quite responsive and supportive. Isn't the real world attack that you simply isolate a namecoin user from the wider namecoin network? That's cheap for state level attackers. I'd imagine OnioNS should have a massive advantage here because Tor has pinned directory authorities, who presumably help OnioNS accurately identify honest quorum servers. It's doable to construct a Bitcoin or Namecoin client that authenticates certain semi-trusted peers to retrieve blocks from, and panics if it can't securely contact them. Electrum is an example of this kind of protocol (though it does SPV verification rather than full verification of the data it receives). This is a client implementation issue (and one that I agree is important), not an issue with Bitcoin or Namecoin as a whole. An end user will be much more likely to notice when a Namecoin or OnioNS name changes, compared to when a .onion name changes. So this isn't really a clear win for .onion -- it's a tradeoff, and which is more secure depends on which end users we're talking about, and what threat model we're dealing with. This is false. Users must enter the .onion address from somewhere. If they go through a search engine, then yes the .onion address itself is hard to remember, especially if they visit many sites. Key poems address this. If however they employ bookmarks, copy from a file, etc., and roughly proposal 244 gets adopted, then an attacker must hack the user's machine, hack the server, or break a curve25519 public key. Yes, a search engine covers .onion addresses should ask users to bookmark desirable results, as opposed to revisiting the search engine, mostly for the protection of the search engine. I think you will find that a number of users are unlikely to exclusively use bookmarks and not use web links. Hyperlinks are an incredibly useful feature which many users are not going to throw out. From what I can tell, your argument makes certain assumptions. Making other assumptions changes the result. Hence, as I said, it's a tradeoff, and which is more 'secure' depends on which end users we're talking about, and what threat model we're dealing with. Cheers, - -Jeremy Rand -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVxwC/AAoJEAHN/EbZ1y06y74P/2CckbR7wvbJhpnkAugtnRpN P5lxDFEEfHF/JD5Sq83rKzB0HJXq/3DiQsta/0bZpWaJP3Oaa9rSQpmVRG7UqA0D RcNHuGnlVG1saAHNgHPk52d6++3j/fE0qcxLkhM6JkeCvMtkXGq/vkzMIVio2/mW yu4b94hDHKtx9QKNTEME68Zq20OaO7zlb8Fa8ymhM6C3C746pskeILp/AwOLxs3s WOrhuLPAKbijovFfV4L48fKallywL/PNS1QreF+QHMfaA8OYmbrefRhJraBCmcED Sc92dh4eLhn8YMU2SuDtoSm6C6N974UF5md4eM9TF64T+vgS8ez0wG/WOtsC72Gy aJ2kDr+5ZgoUx6VrirKCuWIIUyKlGBViIKkoS2vrrcsBIHtq9IlRFZGjUGo0eI9t OrVY9A56lgIl7n4lc1lVYquz8lP75QwmkTh7/12jfF3d6uSE6IoQvUXIm41OWIF1 it7vkWuyCEmfTL5kAB+LYSFsaJlKGxVBGU+M7gXxdDSAdlNsStVJI3fSkspWiYCr +bPcWK0k0WKm4vZWxGIWa5J7qI3t719fCNEJaKZ5Y+3Sg4WkNd0h1TuvXsOw3xiZ tzyeac6QPjnA941AaChUFhxcIDupEfT17HTI1Nfd11i9xDSVSU2FQMXR+kCRRQYA IT+mGnWzQYVPLFE4cnVP =JUdq -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org
