> On 1 Feb 2017, at 01:36, David Goulet <dgoulet@xxxxxxxxx> wrote: > > On 31 Jan (09:02:35), teor wrote: >> >>> On 27 Jan 2017, at 01:58, David Goulet <dgoulet@xxxxxxxxx> wrote: > ... > Your next question is a good one actually so jumping into it! > >> >>> Current implementation doesn't allow two services in the same HiddenServiceDir >>> and for prop224, the ongoing implementation doesn't allow it either. Sharing a >>> directory brings all sorts of uneeded complexity. So if the directory is v3, >>> everything in it will be v3. >> >> How does an application tell the difference between a v2 and v3 >> directory? > > Right now, apart from the "key tag" in the public key file that will be > something like "v3", I don't see any :S ... And I think you are raising a good > point. How can we make it easy for any application *only* looking on disk what > version the hidden service is? > > The onion address has the version encoded into it *but* that would require the > application to do some base32 decode and truncation magic. Not user friendly > enough? Maybe but apart from that, we would need to make it obvious either > with a filename or litterally an extra "version file". I think this would be a good idea: * version 2 hidden services have no version file * version 3 hidden services have a version file with "3" in it and so on... > However, there is kind of an issue rising from this. Imagine that v4 changes > the onion address format because new crypto. We'll end up with a problem where > the how to extract the version from the address is actually version > specific... A solution to that is that "whatever size/encoding the address is, > version will ALWAYS be the last 1 byte." > > Thoughts? I think it is a good idea to make the version the last byte of the address. But I also think that a version file is a good idea to make it easy for applications to discover the on-disk version. Otherwise, the algorithm would have to be something like: * look for a hostname file * read the first line * find the address in that line * if the address is N characters long, version 2 * do we promise we will never have addresses this long in future versions? * base32 decode that line * do we promise addresses will always be base32? * read the last byte * do we promise addresses will always have the version in the last byte? >> >> What's the supported method, that we will continue to support in >> future, regardless of key or algorithm changes? > > Not 100% sure what you mean by "supported method" but I'll take a guess. Those > are the one that comes to mind: > > - Single onion service > - Client auth (only basic for now, we don't have stealth specified) > > Also, every single Hidden Service torrc option will be supported for v3 > *EXCEPT* the Tor2Web one. > > Hope that answers. > ... Actually, what I meant was: "What can an application do to find the hidden service version, that we always promise will work in any future version?" That's what we're discussing above. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev