On 1 Feb 2017, at 01:36, David Goulet dgoulet@ev0ke.net wrote:
On 31 Jan (09:02:35), teor wrote:
On 27 Jan 2017, at 01:58, David Goulet dgoulet@ev0ke.net 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 ------------------------------------------------------------------------