[tor-dev] Future Onion Addresses and Human Factors

[Jeremy Rand]

-----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-----