Re: [tor-dev] Future Onion Addresses and Human Factors

[grarpamp]

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

[Philipp Winter]

On Mon, Aug 10, 2015 at 09:36:22PM +, Alec Muffett wrote:
> On Aug 10, 2015, at 2:00 PM, Philipp Winter  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
___
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

[Alec Muffett]

> On Aug 10, 2015, at 2:00 PM, Philipp Winter  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/ 


—
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

[Philipp Winter]

On Mon, Aug 10, 2015 at 08:47:05AM +0100, bernard wrote:
> > On 9 Aug 2015, at 23:43, Philipp Winter  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
___
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

[bernard]

> On 9 Aug 2015, at 23:43, Philipp Winter  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


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

[Alec Muffett]

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

https://en.m.wikipedia.org/wiki/Quipu_Directory

___
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

[Philipp Winter]

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

[Nick Mathewson]

On Sat, Aug 8, 2015 at 9:05 AM, Roger Dingledine  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

[Ben Laurie]

On Sun, 9 Aug 2015 at 13:29 Alec Muffett  wrote:

>
> On Aug 9, 2015, at 12:36 PM, Ben Laurie  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] Future Onion Addresses and Human Factors

[Alec Muffett]

> On Aug 9, 2015, at 12:36 PM, Ben Laurie  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

[Ben Laurie]

On Sat, 8 Aug 2015 at 13:12 Alec Muffett  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

[Jeff Burdges]

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

[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-
___
tor-dev mailing list
tor-dev

Re: [tor-dev] Future Onion Addresses and Human Factors

[Jeff Burdges]

> 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

[Jeremy Rand]

-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
>> 
>> https://github.com/Jesse-V/OnioNS-literature
> 
> 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-
___
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

[Jeff Burdges]

> On Sat, Aug 08, 2015 at 11:36:35AM +, Alec Muffett wrote: 
> > 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

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.


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

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.


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

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
> 
> https://github.com/Jesse-V/OnioNS-literature

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



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

[grarpamp]

On Sat, Aug 8, 2015 at 7:36 AM, Alec Muffett  wrote:
> 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,

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

[bernard]

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 th

Re: [tor-dev] Future Onion Addresses and Human Factors

[David Goulet]

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]

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

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

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

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.

> 
> 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.  :-)

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



signature.asc
Description: Digital signature
___
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

[Alec Muffett]

> On Aug 8, 2015, at 1:44 PM, Paul Syverson  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 ” 
bookmarked somewhere, which is more direct and unambiguous than the 
“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



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

[Alec Muffett]

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

> On Aug 8, 2015, at 2:05 PM, Roger Dingledine  wrote:
> 
> 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
>  
> 


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

[Alec Muffett]

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



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

[Roger Dingledine]

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.

--Roger

___
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

[Paul Syverson]

Hi Alec,

On Sat, Aug 08, 2015 at 11:36:35AM +, 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:
> 
> 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.  :-)
> 

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


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Future Onion Addresses and Human Factors

[Alec Muffett]

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



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

[Alec Muffett]

> 
> On Aug 8, 2015, at 12:36 PM, Alec Muffett  wrote:
> 
> 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
> 


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



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