[tor-dev] prop224: Ditching key blinding for shorter onion addresses

[George Kadianakis]

Lunar <lunar at torproject.org> writes:

> [ text/plain ]
> George Kadianakis:
>> this is an experimental mail meant to address legitimate usability concerns
>> with the size of onion addresses after proposal 224 gets implemented. It's
>> meant for discussion and it's far from a full blown proposal.
>
> Taking a step back here, I believe the size of the address to be a
> really minor usability problem. IPv6 adressses are 128 bits long, and
> plenty of people in this world now access content via IPv6. It's not a
> usability problem because they use a naming—as opposed to
> addressing—scheme to learn about the appropriate IPv6 address.
>

That's true. Naming systems are indeed the way to go wrt UX. The future sucks
if our users are supposed to use 24 (or 56) random characters as addresses.

That said, the current IPv6 naming scheme (DNS) is far from perfect as
well. Tor would never use it (or any other system with similar threat model).

Furthermore, all the _secure naming systems_ that have been suggested have
their own tradeoffs. They are either centralized, or they use blockchains, or
they require money, or they require a whole network/community to exist, or they
have annoying name-squatting issues, or they require a non-anonymous
registration, or they save HS history on disk, or their protocol is three times
more complicated than Tor itself, or ...
      
So it's not like we have the perfect solution on the naming scheme right now.
We likely need plenty of trial experimentation before we decide on one (or
multiple) naming cheme becoming the official.

We really need to start serious work in this area ASAP! Maybe let's start by
making a wiki page that lists the various potential solutions (GNS, Namecoin,
Blockstack, OnioNS, etc.)?

> While I do think we should think of nicer representation for the new
> addresses than base32, and we should adress that, working on a naming
> system sounds like an easier way out to improve onion services
> usability than asking people to remember random addresses (be them 16 or
> 52 characters-long).
>

Agreed that base32 is not very good as far as encoding goes.

Regardless of the naming system that we need to deploy, we should also
acknowledge that we need a good address encoding scheme anyway, as not all HSes
will use the naming system. This is also the case with IP addresses: many
people mess with IP addresses everyday (for config files, etc.)

I recently read this paper from USENIX which is a UX study on fingerprint
encodings:
    https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/dechand
We might be able to learn somethign from it. For example, they found out that
alphanumeric encodings (like base32) make for the worst experience when
compared to other encodings (pure numeric, unrelated words, sentences, etc.).

Finally, if we acknowledge that at least some people will have to mess with the
raw addresses themselves, another benefit of the addresses being small is that
they are easier to verify by hand (verifying a 24 characters fingerprint, is
easier than verifying a 54 characters fingerprint).


> (I now plenty of people who type “riseup” in the Google search bar of
> their browser to access their mailbox… They don't even want to/can't remember
> an URL. Hardly a chance they will remember an onion address, whatever
> its size.)
>

Indeed. We need a good naming scheme if we ever hope for onion services to
become widespread.

> Maybe it would be worthwhile to ask the UX team for input on the topic?
>

I think that would be a good idea indeed.