[tor-dev] RFC of proposal draft for "Migration to ed25519 HS identity keys and privacy-preserving directory documents"

George Kadianakis desnacked at riseup.net
Sun Sep 22 00:10:11 UTC 2013

Nick Mathewson <nickm at alum.mit.edu> writes:

> On Fri, Sep 13, 2013 at 10:39 AM, George Kadianakis
> <desnacked at riseup.net> wrote:
>> Here is another HS proposal draft.
>  [...]
>> 1.1. From the PoV of Hidden Services:
>>   I see (at least) three migration strategies here. I'm not sure which
>>   one is better so I'll write all of them and we can then discuss them
>>   and pick one.
>>   a) After proposal XXX is implemented, Tor (configured as an HS) will
>>      only publish HS V3 descriptors by default. There will be a torrc
>>      parameter that the HS operator can use, that turns on publishing
>>      of HS V2 descriptors for backwards compatibility with the old HS
>>      address (the old identity key must be kept around).
>>   b) After proposal XXX is implemented, Tor (configured as an HS) will
>>      publish both V3 and V2 HS descriptors for each Hidden
>>      Service. There will be a torrc parameter that turns off
>>      publishing of V2 HS descriptors. This parameter will eventually
>>      be switched off by default.
>>   c) After proposal XXX is implemented, Tor (configured as an HS) will
>>      only publish V3 HS descriptors. The code that publishes V2
>>      descriptors can be disabled or removed. HSes who want to publish
>>      V2 descriptors (and keep the same address) will have to maintain
>>      two copies of Tor -- one running the latest Tor version, and
>>      another one running an older version that supports V2
>>      descriptors.
>>   The engineer inside me tells me to go with c), but I feel that it
>>   leaves all the burden to the HS operators.
>>   I haven't checked how much implementation effort doing a) or b)
>>   would take us.
> Let's also consider d)
>    Exactly like a, except that if we find a hidden service with a
> RSA1024 hidden service identity key, the default behavior is to
> publish both V2 and V3.  Otherwise, the default is to publish V3 only.

Good idea!

>> 1.2. From the PoV of the HS client:
>>   Tor clients can distinguish new-style HS addresses from old ones by
>>   their length. Legacy addresses are 16 base32 characters, while new
>>   ones are 56 (XXX) base32 characters.
> Are you sure?  Assuming that the addresses are 255 bits long, we can
> do it in 51 base32 characters.  If they're 256 bits long, we can round
> up to 52 base32 characters, and reserve the leftover 4 bits as a
> version field or something.  How did you get 56 here?

Yep, you are right.

(I did 'len(base64.b32encode("a"*32))' in Python, which was a mistake
for base32 since 32 is not a multiple of 5.)

>>   If Tor is asked to connect to a legacy address it SHOULD throw a
>>   warning and advocate the use of new-style addresses (it should still
>>   connect to the HS however). In the future, when old-style HS
>>   addresses are close to depletion, we can introduce a torrc parameter
>>   that blocks client connections to old-style HS addresses.
> I think this warning is likely to be obnoxious in practice, since it
> won't tell users which address they should use instead.
>> 1.3. From the PoV of HS directories:
>>   Tor relays will advertise themselves as HSDirV3 servers using the
>>   "hidden-service-dir" router descriptor line.
> Don't they already do that to advertise themselves as v2 hidden
> service directories, or am I mistaken?

I meant that they will also have to append '3' in their
hidden-service-dir line.

I think it currently looks like this:
opt hidden-service-dir
""" (and it defaults to version 2)

and after this proposal it should look like this:

opt hidden-service-dir 2 3

>>   For a while, relays will also continue being HSDirV2 servers. We will
>>   specify a timeout period of X months (4?), after which relays will
>>   stop being HSDirV2 servers by default (using the HidServDirectoryV2
>>   torrc parameter).
> X months starting when?  It's probably not the most user-friendly idea
> to stop supporting the current hidden service design before the new
> code is stable, for instance.

Hm, maybe we should change those "X months" grace periods to "When
0.2.6.x. becomes stable" or to "When 0.2.6.x. becomes stable && no
earlier than in X months"?

>> 1.4. From the PoV of directory authorities:
>>   Authorities will continue voting for HSDirV2 servers. Eventually,
>>   when all relays have upgraded and no one is claiming to be HSDirV2,
>>   we can disable and remove the relevant code.
>> XXX Need to specify grace periods.
>> XXX What did I forget?
> Should there be any means to link new/old identities?  In other words,
> if I have been running OLD = old19jkbba73bap5.onion, and I am now
> going to be changing my address to NEW =
> new8787dsfg9gprioj57669h8941bvyzbli81b9ayeotoabervla.onion, should
> there be any way to tell people "hey, use the new one instead", or for
> the new one to prove that it is the same as the old one?
> One fine option here is "no", since most of the solutions I can think
> of are insecure and invite enumeration opportunities.  But people may
> want to do this anyway, and I worry that if they do, the solutions
> they pick might be even worse than the ones I come up with.

I also thought that something like this could be useful, but I didn't
want to add more implementation pain to this proposal.

A plausible solution here (that doesn't lead to obvious enumeration
opportunities) is to have Hidden Services send a "You are using my old
HS address. Try this one" relay cell right after the RP circuit has
been spliced and before the RELAY_COMMAND_BEGIN command has been sent
by the client. This way the the new address is not leaked to HSDirs,
IPs or RPs.

Still, I'm not sure if this is worth the implemention effort.

More information about the tor-dev mailing list