-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/08/2015 11:39 PM, Jeff Burdges wrote:
On Sat, 2015-08-08 at 08:44 -0400, Paul Syverson wrote:
One is to produce human meaningful names in association with onion addresses. Coincidentally Jesse has just announce to this same list a beta-test version of OnionNS that he has been working on for the Tor Summer of Privacy. See his message or
OnioNS has a relatively weak adversary model, like Namecoin, right? It's certainly plausible that's good enough for most users, including all financial users, but maybe not everyone.
There are several approaches to improving upon that adversary model :
- Pinning in the Name System - If a name X ever points to a hidden service key, then X cannot be registered to point to a different hidden service key for 5 years. Alternatively, if our name system involves another private key, then X cannot be registered under another private key for 5 years.
- Pinning/TOFU in the browser - If my browser ever visits X then it locks either the .onion key and/or the TLS key permanently. Alternatively pin both but one at a time to change. Sounds bad for Tails, etc. though.
- Awareness - Just yell and scream about how OnioNS, Namecoin, etc. are nowhere near as secure as a .onion address. And especially tell anyone doing journalism, activist, etc. to use full .onion addresses.
I'm not 100% sure what you mean by saying that OnioNS's and Namecoin's adversary models are comparable. To my knowledge, they're quite different in the respect that OnioNS relies on a quorum of directory authorities, while Namecoin relies on a quorum of mining hashpower. Which is "better" probably depends on your threat model. 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. 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). Note that right now -- though hopefully not in the future - -- this kind of attack is easier than it should be because a majority of Bitcoin hashpower (and with it Namecoin) is located in China. I'm not sure about OnioNS's design, but in Namecoin's design, a 51% attack is easily detectable (you'll see blocks getting orphaned in a way that makes a targeted name not get renewed even though the renewal transaction is clearly visible and being relayed). It's also easily detectable specifically which names were targeted by the attack. Regarding pinning, there are also some half-formed proposals related to that for Namecoin, which would make a 51% attack ineffective at stealing a name (it would instead simply be a DoS attack on that name, which would cost continued hashpower to sustain). Personally I'd love to see these proposals implemented, although getting the appropriate level of review to make sure everything works as we intend takes some time. (This would be a hardfork to the consensus rules, so it takes a lot of carefulness.) In any event, security only matters if the end users can effectively use it. 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. There are probably a significant number of cases where Namecoin (or OnioNS, or something similar to either) would defend against attacks that .onion wouldn't. (The inverse is, of course, also probably the case.) Cheers, - -Jeremy Rand -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVxtuSAAoJEAHN/EbZ1y06SVoQAMaa03n2/onHeqtwMzfSRwEO IzrsyrxLCxJhPCAGH4gvuGkU/rqNJRT4BhwwTCvtgoEnYNWe0dxoc29bNM76KR0f Ksq5//kgm73sDyyeRw4jxP3SpMzucc1BoyTBEeJdYuL8hdBwBwkOrd32C+ee/7vu /OUzisy68apzQFHZDlXY5HS6rp+vdOj1uKUglhDM9nSx73kSdOnpvuxZm9PfYdaR OXBmZ9Lhk8hAYKhoxdTI+I5I8KNiCZV/uWkDSfDs+RUuL2dAvdEcP3uq5lQoIGyO tOgBqBSpBAk39ihA7YplmhL3YSJcQ4yfo4rY68PDby+sGI/quZ5YGJjOEyKW0TF2 uObuDQz+1ajD/WPiaQ9I6xo2jJE2vQkMrqfCe83YsR8oOmpN3f+YWm/fgs/EoDul tG50rwr76egQL+EphJFYvH35YKAwoXNowDlTpGMMCanRC0pOoQAdpmyPvJv38E56 mZSC42oeFgV/vjnSEtKBtnthfg6GHap87XHp+nX//Ry5v+fxo9t94QyGUrAxQtLQ 0MJ4athw3QTi8QJYa6y1DktbIze5dStqteBKK+W7EvrXxNS0eJYL9vJvKPEyu75x dqhzFZTsFjinv9Dgn/YG665WlvVpDkc36wn/Cj6yXP1kT2Prpo+ekmdLFxJUiQ9l zYtb7Vw4vTw0KOzsrH8E =UgpZ -----END PGP SIGNATURE-----