Hi All,
Having Beer with Donncha, Yan and others in Berlin a few days ago, discussion moved to Onion-Address Human Factors.
Summary points:
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.
2) example of the above: there are already “in the field” a bunch of onion addresses “passing themselves off” as other onion addresses by means of common prefixes.
3) next generation onion addresses will only make this worse
4) from Proposal 244, the next generation addresses will probably be about this long:
a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion
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
6) using underscores would be a pain (tendency to have to use SHIFT to type)
7) using dots would pollute subdomains, and colons would cause parser confusion with port numbers in URIs
8) being inconsistent (meaning: “we extract the second label and expunge anything which is not a base32 character”, ie: that with-hyphens and without-hyphens) may help or hinder, we’re not really sure; it would permit mining addresses like:
agdjd-recognisable-word-kjhsdhkjdshhlsdblahblah.onion # illustration purposes only
…which *looks* great, but might encourage people to skimp on comparing [large chunks of] the whole thing and thereby enable point (2) style passing-off.
9) appending a credit-card-like “you typed this properly” extra few characters checksum over the length might be helpful (10..15 bits?) - ideally this might help round-up the count of characters to a full field, eg: XXX in this?
a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdXXX.onion
10) it might be good to discuss this now, rather than later?
Hence this email, in the hope of kicking off a discussion between people who care about human factors. :-)
- alec
— Alec Muffett Security Infrastructure Facebook Engineering London
On Aug 8, 2015, at 12:36 PM, Alec Muffett alecm@fb.com wrote:
appending a credit-card-like “you typed this properly” extra few characters checksum over the length might be helpful (10..15 bits?) - ideally this might help round-up the count of characters to a full field, eg: XXX in this?
a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdXXX.onion
For the avoidance of doubt: I am not proposing use of special-case capital letters for checksums. I merely use capital letters for emphasis.
— Alec Muffett Security Infrastructure Facebook Engineering London
Hi Alec,
On Sat, Aug 08, 2015 at 11:36:35AM +0000, Alec Muffett wrote:
Hi All,
Having Beer with Donncha, Yan and others in Berlin a few days ago, discussion moved to Onion-Address Human Factors.
Summary points:
- 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.
- example of the above: there are already “in the field” a bunch of
onion addresses “passing themselves off” as other onion addresses by means of common prefixes.
next generation onion addresses will only make this worse
from Proposal 244, the next generation addresses will probably be
about this long:
a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion
- 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
- using underscores would be a pain (tendency to have to use SHIFT
to type)
- using dots would pollute subdomains, and colons would cause
parser confusion with port numbers in URIs
- being inconsistent (meaning: “we extract the second label and
expunge anything which is not a base32 character”, ie: that with-hyphens and without-hyphens) may help or hinder, we’re not really sure; it would permit mining addresses like:
agdjd-recognisable-word-kjhsdhkjdshhlsdblahblah.onion # illustration purposes only
…which *looks* great, but might encourage people to skimp on comparing [large chunks of] the whole thing and thereby enable point (2) style passing-off.
- appending a credit-card-like “you typed this properly” extra few
characters checksum over the length might be helpful (10..15 bits?)
- ideally this might help round-up the count of characters to a full
field, eg: XXX in this?
a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdXXX.onion
- it might be good to discuss this now, rather than later?
Hence this email, in the hope of kicking off a discussion between people who care about human factors. :-)
These are all good points. Not sure you are so much kicking off as joining some discussions. Maybe you will help pull several discussions into some sort of coordination. Anyway, I would say that there have been broadly two approaches to human factors and onion addresses which the above should complement well.
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
https://github.com/Jesse-V/OnioNS-literature
The other that I am aware of is to bind onion addresses in a human meaningful way to existing names, typically registered domain names, but could be e.g. a Facebook page rather than a domain name per se. A preliminary description of this can be found in "Genuine onion: Simple, Fast, Flexible, and Cheap Website Authentication". Both paper and slides pdf can be found under http://ieee-security.org/TC/SPW2015/W2SP/
I have since that presentation been talking to Let's Encrypt folk and others about ways to expand and revise the ideas therein. Some of us have also worked on a related Tor Proposal on single onion services (aka direct onion services vs. location-hidden aka double onion services) that would be posted if I could ever find time to just add a little more to make it self-contained. We expect to have a revised and expanded version of the above paper in the not too distant future. (This week I'll be giving a course about Tor at the SAC Summer School and the Stafford Tavares Lecture at SAC in New Brunswick, but will be almost completely skipping onion services since there is basically infinite amounts of Tor things to talk about.) Picking this up again significantly in about a week and a half or thereabouts.
aloha, Paul
On Aug 8, 2015, at 1:44 PM, Paul Syverson paul.syverson@nrl.navy.mil wrote:
Hi Paul!
I think it would be valid to propose a third direction, which is to partially give-up arguing about the importance of Zooko’s Triangle and instead make attempts to meet human beings and computers somewhere in the middle.
I don’t believe that this direction should preclude development of the other two - they might indeed be complementary - but making Onion addresses accessible in the ways that an IPv4 “dotted quad” is, or that an IPv6 “::” field-pad does, cannot be a bad thing.
There is, as you point out:
One is to produce human meaningful names in association with onion addresses.
…which is akin to the layer that DNS provides atop IP addressing; everyone with a domestic DSL router probably has “http://192.168.1.1 http://192.168.1.1/” bookmarked somewhere, which is more direct and unambiguous than the “http://router http://router/.local” that it may also masquerade as, by providing DNS bootstrap through DHCP.
The other that I am aware of is to bind onion addresses in a human meaningful way to existing names, typically registered domain names,
I recall the discussion we had inside Facebook, along the lines of “why don’t we register “onion.facebook.com” and issue a redirect, rather than forcing people to type this gibberish?” - an argument which was won by the observation “we are putting this out for people to have trust, and why should we make them trust DNS+redirection when we can instead give them something direct and unambiguous"
You’ll gather that I like “direct and unambiguous”. :-)
Hence: let there be innovation.
Please let a thousand discovery mechanisms bloom - including peer-to-peer directories and tweeted URLs.
But, what they boil down to, please let *that* be human-readable, too. The more I like about it, the more I like:
a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdxxx.onion
…where the final “xxx” is a 15-bit truncated secure hash of the rest of the original raw address bitstring.
That way people looking to quickly compare addresses can check the first octet, and the last, and sample a few of the inner ones (“…people compare glyphs not words…” / “there’s IEVXD and there’s E0RFF, I like that one, it’s like Eeyore in Winnie-The-Pooh, and 0WLGM reminds me of Owls") and be reasonably satisfied and reasonably secure.
And the XXX can be checked by the browser and tell the user that they’ve goofed-up cut/paste/typing-it-in. And then they bookmark it once it loads.
- alec
— Alec Muffett Security Infrastructure Facebook Engineering London
Gah, I am evidently having a bad day with e-mail, so I am going to send a typo correction with this and then go do something else instead.
Corrections in caps, below.
— Alec Muffett Security Infrastructure Facebook Engineering London
On Aug 8, 2015, at 2:14 PM, Alec Muffett alecm@fb.com wrote:
Please let a thousand discovery mechanisms bloom - including peer-to-peer directories and tweeted URLs.
But, what they boil down to, please let *that* be human-readable, too. The more I THINK about it, the more I like:
a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdxxx.onion
…where the final “xxx” is a 15-bit truncated secure hash of the rest of the original raw address bitstring.
That way people looking to quickly compare addresses can check the first QUINTET, and the last, and sample a few of the inner ones (“…people compare glyphs not words…” / “there’s IEVXD and there’s E0RFF, I like that one, it’s like Eeyore in Winnie-The-Pooh, and 0WLGM reminds me of Owls") and be reasonably satisfied and reasonably secure.
And the XXX can be checked by the browser and tell the user that they’ve goofed-up cut/paste/typing-it-in. And then they bookmark it once it loads.
Hi,
Right now, .onion URLs are not human readable. Neither are they easy for humans to recognise OR recall.
The way information is presented to humans can greatly influence how we recognise, recall it and process it.
The ideal situation is for the user to recognise a piece of information. It takes less cognitive processing to do this. This is not possible here as they are required to type the URL into the browser.
In this case the user will be required to recall the address, as someone reads it out to them, or they read it off a device screen. Recall is more difficult for humans to carry out.
Alec’s idea below is essentially the “chunking” of .onion addresses. It is an often used technique when it comes to many human-computer interactions that require humans to process information.
Research shows that humans’ "short-term memory” has different characteristics to our “long-term memory. [1, 2]
This short term memory (also called working memory) provides temporary storage of information and has a limit (often compared with a channel's capacity).
This working memory capacity can be increased by information chunking - the information is recoded into many chunks which contain a number of bits per chunk. Bit in this context means an item of information.
In our context it would be equivalent to a letter or number in the URL.
As stated in Millers paper below the so-called 'magic number’ is seven +/-2 bits, per chunk.
While the definition of a chunk is not strict, in terms of .onion addresses, this could be achieved through experimentation and drawing on already published research. (Haven’t found any yet, but thats not to say it isn’t out there). The lower end of Millers chunk size, 5, would be a good place to start.
The human is able to see patterns, categories, groupings and use this to increase her/his working memory temporarily.
As someone mentioned already this aids humans in recalling telephone numbers, 08057-282-9320, instead of 080572829320.
In this case I have chunked this number to take into account the chunk 08057 because for me it is a manageable sized chunk and the pattern “282” in the middle.
Chunking may also assist the user in recognising they have transferred the information correctly.
It would be interesting to observe in a usability test, how a user would transfer a .onion address from say, a chat session to their browser.
If the address was chunked it could be expected it would assist them in seeing the difference between:
a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sd5sp.onion
the real URL and
shdue-duqld-7p3i5-ievxd-m6oeu-27388-g607q-e0rff-dw9jm-ntwkd-srfcg.onion
a malicious URL.
It would be wonderful to see some user research into this. In terms of UI, could the Tor Browser warn the user “This looks similar to, but not the exact same as, a URL you have stored. Do you really want to follow the link?”?
There is however, a balance to be struck with using information chunking. A users' working memory can be overloaded with presenting them with too much information.
This may be an issue here as the proposed .onion address is 52 letters?
The ideal situation would be for the information to eventually transfer from the users working memory to their long-term memory so they can type the address every time they want to - the address would be memorised.
I would suspect this will not be achievable in most instances, as the process of “storing” information to their long term memory requires repeated exposure to the information - I would not expect the user to willingly type a 23 word long URL (256 bits, 11 bits in a word?) into their browser repeatedly.
This could easily be overcome by the user bookmarking the URL in the Tor browser for future use, once it has been entered correctly.
This would be an improvement over the current situation.
The second topic would be to work out what character would be best used to visually represent that chunking.
For telephone numbers this can be a space, hyphen, period, forward-slash. It would be best to find out from users (or previous research) what would help here.
Again, experimentation could point to characters that would help here. Please consider carrying out some research into this.
The above will improve the situation, but we would still be requiring the user to recall multiple random strings of characters (even with a checksum).
While I don’t know about the possibility of this from a technical point of view, an improvement on this (from the point of view of the usability of .onion addresses) *may* be to produce pronounceable word .onion addresses. [3, 4]
So instead of:
a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdt5sp.onion
it would be:
correct-battery-horse-staple-chair-banana-table-river-pizza.onion
or using an already established dictionary:
fat-gin-keg-log-oak-pit-pup-darn-fury-knee-mark-year-wand-tram-it.onion
If the goal is to improve the usability of .onion addresses, I would support Alec’s suggestion of chunking addresses.
I would extend it by suggesting the addresses are someway human readable.
I would also support carrying out user research with users to come up with approaches the user will understand. I will happily help if there is willingness.
Thanks, Bernard
[1] The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information, http://ruccs.rutgers.edu/faculty/pylyshyn/Proseminar06/Miller_MagicNumber7c.... [2] https://www.interaction-design.org/encyclopedia/chunking.html [3] https://xkcd.com/936/ [4] https://cups.cs.cmu.edu/soups/2012/proceedings/a7_Shay.pdf
On 8 Aug 2015, at 14:19, Alec Muffett alecm@fb.com wrote:
Gah, I am evidently having a bad day with e-mail, so I am going to send a typo correction with this and then go do something else instead.
Corrections in caps, below.
— Alec Muffett Security Infrastructure Facebook Engineering London
On Aug 8, 2015, at 2:14 PM, Alec Muffett alecm@fb.com wrote:
Please let a thousand discovery mechanisms bloom - including peer-to-peer directories and tweeted URLs.
But, what they boil down to, please let *that* be human-readable, too. The more I THINK about it, the more I like:
a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdxxx.onion
…where the final “xxx” is a 15-bit truncated secure hash of the rest of the original raw address bitstring.
That way people looking to quickly compare addresses can check the first QUINTET, and the last, and sample a few of the inner ones (“…people compare glyphs not words…” / “there’s IEVXD and there’s E0RFF, I like that one, it’s like Eeyore in Winnie-The-Pooh, and 0WLGM reminds me of Owls") and be reasonably satisfied and reasonably secure.
And the XXX can be checked by the browser and tell the user that they’ve goofed-up cut/paste/typing-it-in. And then they bookmark it once it loads.
------------- Bernard Tyers If you want to contact me please do: http://contactme.ei8fdb.org
On Sat, Aug 08, 2015 at 11:36:35AM +0000, Alec Muffett wrote:
- from Proposal 244, the next generation addresses will probably be
about this long:
a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion
- 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
We could make the .onion URL human recognizable, but not actually human typeable. I like key poems : https://moderncrypto.org/mail-archive/messaging/2014/000125.html
In fact, there is no need to conceptualize this as a URL except for convenience. We could provide a .onion key poem library so that TBB, etc. can display them when you mouse over the URL bar.
- being inconsistent (meaning: “we extract the second label and
expunge anything which is not a base32 character”, ie: that with-hyphens and without-hyphens) may help or hinder, we’re not really sure; it would permit mining addresses like:
agdjd-recognisable-word-kjhsdhkjdshhlsdblahblah.onion # illustration purposes only
…which *looks* great, but might encourage people to skimp on comparing [large chunks of] the whole thing and thereby enable point (2) style passing-off.
There are a couple choices for mappings for the non-essential characters in base 32 encodings. I believe the usual one was designed to make spelling fuck impossible or some stupidity like that. I think the one GNUNet uses was selected to provide as much flexibility as possible. It's no worse for type-o squating if u and v map to the same value and a few similar things.
- appending a credit-card-like “you typed this properly” extra few
characters checksum over the length might be helpful (10..15 bits?)
- ideally this might help round-up the count of characters to a full
field, eg: XXX in this?
a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdXXX.onion
Yes, checksums help enormously.
Interestingly, there are situations where you're entering a password, but the machine should add a checksum while remaining human readable.
In those situations, there is a clever suggestion by Christian Grothoff that an algorithm tweak the human readable passphrase until some hash is zero.
Pond's PANDA key exchange is an example of when one should do this, although Pond does not.
I doubt that's relevant for .onion URL itself, but maybe worth considering for vanity key poems or something.
On Sat, 2015-08-08 at 09:05 -0400, Roger Dingledine wrote:
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.
A priori, "pet names" sounds vaguely like the GNU Name System (GNS), meaning short names consistent for the user, but not globaly unique.
In GNS, there is a .short.gnu domain so that after you visit facebook's blah.zkey then facebook.short.gnu becomes a meaningful domain. I'd worry however that, if your anti-facebook friend jake sets his preferred short name to facebook, and you visit his zone fist, then he gets facebook.short.gnu on your machine. TOFU world problems. ;)
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.
- Key Poems maybe?
Jeff
-----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
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.
-----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
On Sun, 2015-08-09 at 07:26 +0000, 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
On Sat, Aug 08, 2015 at 11:36:35AM +0000, Alec Muffett wrote:
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.onionagdjd-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.
--Roger
— Alec Muffett Security Infrastructure Facebook Engineering London
On Aug 8, 2015, at 2:05 PM, Roger Dingledine arma@mit.edu wrote:
https://urldefense.proofpoint.com/v1/url?u=https://trac.torproject.org/proje... https://urldefense.proofpoint.com/v1/url?u=https://trac.torproject.org/projects/tor/ticket/15622&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0A&m=t0VcFezNAZohjkc7dkqY5Pak9%2BW62AHKDN8z436MZq8%3D%0A&s=50006f472990c7b35011656eec44171543f66f719759d7ee5fd9fdc31fc9b70d
On Sat, Aug 8, 2015 at 9:05 AM, Roger Dingledine arma@mit.edu wrote:
On Sat, Aug 08, 2015 at 11:36:35AM +0000, Alec Muffett wrote:
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.onionagdjd-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
On 08 Aug (11:36:35), Alec Muffett wrote:
Hi All,
Having Beer with Donncha, Yan and others in Berlin a few days ago, discussion moved to Onion-Address Human Factors.
Beers, very nice! :)
[snip]
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
That I like quite a bit!
Right now, with the 16 char address, I doubt very much that people actually type them in the browser, I bet it's still and will continue to be Copy-Paste. As for the verification part that is making sure you have the right .onion, I'm pretty sure this is just ignore by most users and that it is actually worst with vanity address because as long as I see "facebook" in there, that's good enough. Ok, you guys have a pretty epic one that is quite noticeable but let's take Wikileaks upload page for instance "wlupld3ptjvsgwqw.onion", only seeing "wlup" is MOST probably way enough for most of the users and 12 characters are then ignored.
(Altough, most users probably rely on the CA-mafia to get their .onion in a "trusted" ways so anycase the "verification of .onion" situation is pretty bad. ;)
With "banks of char", it makes it much more easier for someone to remember one of them and verify that at least the one I remember is there. It's not perfect but it's a damn good start imo. I remember reading a while back a study about research done at Bell Labs when they were trying to come up with a standard length for the phone numbers in North America (now 7 digits + 3 area code). One of the reasons in the end was the human brain capability of quickly, and for a reasonable amount of time, remembering <= 7 digits.
So, this approach takes advantage of that "human brain quirk" and we should definitely use it to improve onion address verification by users. With 52 characters, there could be 7 blocks of 7 chars (49) and a last block of 3 chars + the 4 unused bits (see below for those). If you remember at least one of those blocks somewhere in the string, I say amazing improvement!
(I would NOT go with different length though, I bet *everyone* will end up remember the smallest one so have them at least all the same length or some of them bigger.)
using underscores would be a pain (tendency to have to use SHIFT to type)
using dots would pollute subdomains, and colons would cause parser confusion with port numbers in URIs
being inconsistent (meaning: “we extract the second label and expunge anything which is not a base32 character”, ie: that with-hyphens and without-hyphens) may help or hinder, we’re not really sure; it would permit mining addresses like:
agdjd-recognisable-word-kjhsdhkjdshhlsdblahblah.onion # illustration purposes only
…which *looks* great, but might encourage people to skimp on comparing [large chunks of] the whole thing and thereby enable point (2) style passing-off.
appending a credit-card-like “you typed this properly” extra few characters checksum over the length might be helpful (10..15 bits?) - ideally this might help round-up the count of characters to a full field, eg: XXX in this?
a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdXXX.onion
See section 1.2 of proposal 224 (NOT 244 ;), there are 4 unused bits when using base32 encoding. I remember we had a discussion about those at the HS meeting [1], ideas where the length, very small checksum ("a la credit card"), or human readable word.
So definitely, this needs to be clarified in the proposal.
- it might be good to discuss this now, rather than later?
Hence this email, in the hope of kicking off a discussion between people who care about human factors. :-)
Totally and if by some email magic we reach a concensus, this should be added to the prop#224 before we do implement it. (Or even it's own proposal if too big.)
Cheers! David
[1] https://blog.torproject.org/blog/hidden-service-hackfest-arlington-accords
- alec— Alec Muffett Security Infrastructure Facebook Engineering London
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Sat, Aug 8, 2015 at 7:36 AM, Alec Muffett alecm@fb.com wrote:
- appending a credit-card-like “you typed this properly” extra few
characters checksum over the length might be helpful (10..15 bits?) - ideally this might help round-up the count of characters to a full field,
a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdXXX.onion
Checksums need to detect more bits than the 0-n number of expected errors. At the apparent 56^(26+10) ~=2^205 above, there may also be no need to give typo feedback if the error rate is unlikely to result in some other valid address. And just where exactly and in what protocols and apps are going to build in that feedback popup... browsers? ssh? MUA? ping? skype?
people wrote:
And just where exactly and in what protocols and apps are going to build in that feedback popup... browsers? ssh? MUA? ping? skype?
Vanity addresses encourage people to only verify the human-readable part
That said, if an address is completely incapable, even hostile to validation by human eyeballs, then what happens is “trust” migrates
Humans give up on long strings of anything because it requires work to validate. If not at first glance different, how many people here give up, pipe to hash, and use the avalanche to compare.
Outside of better introduction, pinning, bookmarking, chaining, namespaces and WOT, humans and strings are just intractable.
On Sat, 8 Aug 2015 at 13:12 Alec Muffett alecm@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).
On Aug 9, 2015, at 12:36 PM, Ben Laurie ben@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
On Sun, 9 Aug 2015 at 13:29 Alec Muffett alecm@fb.com wrote:
On Aug 9, 2015, at 12:36 PM, Ben Laurie ben@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.
Aside: in pursuit of helping Jake register “.onion” as a "special name” in an RFC, I am currently being beaten-up on the IETF discussion mail-list regards the potential future length of onion addresses, and that they may possibly exceed the bounds of DNS’ maximum label length of 63 characters:
https://www.ietf.org/mail-archive/web/ietf/current/msg94332.html https://www.ietf.org/mail-archive/web/ietf/current/msg94332.html
The examples in Proposal 224 are a mere 53 characters long leaving 10 to play with for padding-hyphens and possibly checksum characters.
Nick: Is this likely to need to change? Or might there be a need to encode > 315 bits / 63 chars total?
-a
— Alec Muffett Security Infrastructure Facebook Engineering London
On Wed, Aug 12, 2015 at 11:59 AM, Alec Muffett alecm@fb.com wrote:
Aside: in pursuit of helping Jake register “.onion” as a "special name” in an RFC, I am currently being beaten-up on the IETF discussion mail-list regards the potential future length of onion addresses, and that they may possibly exceed the bounds of DNS’ maximum label length of 63 characters:
https://www.ietf.org/mail-archive/web/ietf/current/msg94332.html
The examples in Proposal 224 are a mere 53 characters long leaving 10 to play with for padding-hyphens and possibly checksum characters.
Nick: Is this likely to need to change? Or might there be a need to encode > 315 bits / 63 chars total?
I don't anticipate this changing.
If there were ever a need to encode more than that number of bits, we'd add an extra label.
On Sat, Aug 08, 2015 at 11:36:35AM +0000, Alec Muffett wrote:
- 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
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.
I worked on implementing the X.500 Directory Project which had similar goals for e-mail addresses. That experience convinced me of the need for simplicity and accessibility at all levels, unless you want to port the entire stack to TorPetSpace and watch the code rot.
On 9 Aug 2015, at 23:43, Philipp Winter phw@nymity.ch wrote:
Vanity onion addresses, for example, might have done more harm than good
Why do you say that? What harm would human readable .onion addresses do? And to who?
As a result, maybe we should make it intentionally *harder* to manage raw onion addresses, just like it's hard to manage raw barcodes.
Humans don’t deal with raw barcodes. They do deal with URLs.
Thanks, Bernard
On Mon, Aug 10, 2015 at 08:47:05AM +0100, bernard wrote:
On 9 Aug 2015, at 23:43, Philipp Winter phw@nymity.ch wrote:
Vanity onion addresses, for example, might have done more harm than good
Why do you say that? What harm would human readable .onion addresses do? And to who?
Vanity addresses encourage people to only verify the human-readable part of an address before clicking on it. That creates a false sense of security, which is already exploited by spoofed onion service addresses whose prefix and suffix mimics the original onion address.
Cheers, Philipp
On Aug 10, 2015, at 2:00 PM, Philipp Winter phw@nymity.ch wrote:
Vanity addresses encourage people to only verify the human-readable part of an address before clicking on it. That creates a false sense of security, which is already exploited by spoofed onion service addresses whose prefix and suffix mimics the original onion address.
That does strike me as a risk.
That said, if an address is completely incapable, even hostile to validation by human eyeballs, then what happens is “trust” migrates to using a bunch of tools which are forgeable, spoofable, hackable, trojanable.
The resultant risk might be worse for its greater resistance to detection.
-a
ps: for an investigation of what happens when you build a “communities” app around “non-human-readable” barcodes and without a discovery mechanism, see this article; such innovation gives me great hope for humanity finding solutions to apparently high-friction technologies, but it also clearly hampers broader inclusiveness, the latter arguably being one of Tor’s most important goals:
http://mashable.com/2014/10/24/hacks-facebook-rooms/ http://mashable.com/2014/10/24/hacks-facebook-rooms/
— Alec Muffett Security Infrastructure Facebook Engineering London
On Mon, Aug 10, 2015 at 09:36:22PM +0000, Alec Muffett wrote:
On Aug 10, 2015, at 2:00 PM, Philipp Winter phw@nymity.ch wrote:
Vanity addresses encourage people to only verify the human-readable part of an address before clicking on it. That creates a false sense of security, which is already exploited by spoofed onion service addresses whose prefix and suffix mimics the original onion address.
That does strike me as a risk.
That said, if an address is completely incapable, even hostile to validation by human eyeballs, then what happens is “trust” migrates to using a bunch of tools which are forgeable, spoofable, hackable, trojanable.
Right. That's why I would integrate these tools into Tor Browser instead of distributing them separately.
Cheers, Philipp
-
Alec Muffett -
Ben Laurie -
bernard -
David Goulet -
grarpamp -
Jeff Burdges -
Jeremy Rand -
Nick Mathewson -
Paul Syverson -
Philipp Winter -
Roger Dingledine