[tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

[s7r]

Hello,

George Kadianakis wrote:
> grarpamp <grarpamp at gmail.com> writes:
> 
>> Skimming thread...
>>
>> Version or not is fine, provided if you want versions you
>> know you must store the bits somewhere, or ensure regex
>> parser rules to recognize and match an intrinsic version
>> represented by entire address format specification itself.
>>
>> Note onion search spiders rely on such address recognition
>> and parsing. So it's not all just about the browser brain urlbar.
>>
>> GPU capacity hasn't hit 16 char yet, mnemonic
>> brain memory has, but that's only happened based on
>> address luck and/or GPU prefixing. We're more or less
>> at the limits, new random bits past 16 won't matter and
>> shouldn't be considered much an argument to brain relavance.
>> Some other brain layer will come along, and if not, there's
>> always search.
>>
>> If version goes in address, I'd wary against putting it last.
>> A lot of things naturally sort and route and default based
>> on higher order bits appear prefixing on the left.. IPv4 IPv6
>> bitcoin PTR DHT filesystem unix tools... the list goes on.
>> A single leading character is not a problem and gives
>> plenty of bits of version capacity regardless of encoding.
>> Trailing version just plain feels shaky to rely on or to
>> advocate to the world as a new standard. Certainly
>> not without consultation with other anonymous overlay
>> projects as to their future needs and direction as well,
>> or to develop such an interop standard.
>>
> 
> Hm, can you please expand on this? I think I understood none of your arguments.
> 
> What's the problem with version field being in the end and tools sorting
> addresses based on higher order bits? Also why does version field being
> in the end makes it shaky to rely on?
> 

None of the arguments make any sense to me either. It doesn't matter if
the version is prefixed or trailed, it can be interpreted the same.

What does Tor using version at the end of address have to do with
advocating to the world as a new standard? New standard for what? What
good would be consulting with other anonymous overlay projects be? Which
projects? This questions are not meant to be answered, let's not turn
this thread counter-productive out of respect for all very busy people
reading.

For me, this looks very good:
https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop224-onion-address&id=50ffab9903880acf55fe387f4d509ecb2aa17f95

chelsea's comments have a good point, but we are pretty sure that a new
version will mean entire different crypto, different public keys thus
different addresses anyway. Moving the version on descriptors entirely
and exclusively won't help since it could only represent one public key
(address), if not it could either create a chicken-and-egg problem
either a false sense of security (equal to the security of the public
key / version that you use to query to the HSDir). So if we're in a PQ
era, have PQ crypto as V4 onion service but do the rendezvous dance
starting with old, vulnerable crypto, we will be doing it wrong.
Otherwise, the operator needs to re-distribute new version different
address so the encoded version won't matter/help. I dislike and don't
see the point of pulling the version byte out of the address. That is
exactly what these lengthy hostnames were missing...

To be frank, the version is not so super important, because:
- prop224 can work perfectly fine even without a version encoded in
address - we are using it so clients can take informed action before
arriving to HSDirs. You cannot confuse a V2 address with a V3 one, and
this should stick for the future from my point of view. Otherwise, why
not start prop 224 with version 0 or 1 encoded into addresses.

- a version change will surely change the entire crypto thus making
address re-use for different versions impossible. It's an
anti-censorship, self-authenticated, uncensored system so key material
under the exclusive control of the user has to be used. At this moment,
and this is unlikely to change, we can accomplish this only by using
whole public keys or at least hash-sums of public keys. With a proper
name system the human-memorable name can be updated with the new version
address.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170131/72f7449c/attachment-0001.sig>