Hello, George Kadianakis wrote: > grarpamp <grarpamp@xxxxxxxxx> 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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev