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

[U+039b]

Hi!

George Kadianakis a écrit :
> 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 ...

After some discussions, I started to write the specifications of a
naming service. It is based on Reed-Solomon[0] - shards are distributed
over multiple nodes (which are HS to) and then signed. Thus, there is no
node which has the complete registrations information. To recover the
entire list of HS, multiple nodes have to be compromised or brute
forced. Shards are replicated which helps to prevent a DoS. Furthermore,
registrations are anonymous and volatile - the HS registers itself, a
registration has to be refreshed every hour or every day (the refresh
period has to be well studied in order to have a reasonable traffic).
Volatility allows to keep mapping tables in RAM.

Regarding the trade-offs listed above, the only one I cannot handle is
the name squatting. Regarding the others, the protocol will be simple
(based on Tor communication) and few nodes are required to start the
service.

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

I would be happy to take part of a working group which tackles this topic.

Regarding encoding, we can even use base64, base91, etc. I wrote a
stupid HS pet name generator[1] which encodes the onion address with a
dictionary of real words. It generates a set of 16 words for next gen HS.

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

[0] https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction
[1] https://gitlab.s1.0x39b.fr/lambda/onion-pet