[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Let's identify which measurement-related tools need work when relays switch from RSA identities to ed25519 identities



> It's true, dropping the fingerprint is quite invasive and might break
> things.  But that's why we're making plans now to make this transition
> as smooth as possible.
>
> However, I don't think that we can get away by just replacing the
> existing 20 byte long RSA key digest with a 20 byte long hash of the
> new, 32 byte long ed25519 key.  There are probably cryptographic
> reasons for that.  But in addition to that, there should be a time
> when relays use both fingerprints in parallel so that directory
> authorities and other tools can build a map from old to new
> identities.  Otherwise, relays would lose all their history only
> because they are switching from RSA to ed25519, and wouldn't that be
> sad?  There might be more reasons that I'm currently not thinking of.
>  But: I'm not making this call, I'm just thinking about the possible
> impact of this change and which code needs to be updated.
>
> How about we talk more about this in Berlin together with Nick?  Maybe
> take a look at the list I wrote and think of other code that will need
> work when this change actually takes place?

Certainly, sounds good! For what it's worth my concern is about the
fingerprint's longstanding role as the relay identifier. Some spots
off the top of my head...

* The control spec allows you to query descriptors by fingerprint or nickname.
* Circuit events and most other things citing relays do so by
fingerprint or fingerprint~nickname.
* Atlas, Globe, and just about every tool that allows you to look up
relay information does so by fingerprint.
* In Stem anything related to identifying a relay does so by fingerprint.

No doubt there's many, many other things that'll break too. This is
the main identifier of a relay and I'd expect mucking with it to break
all the things. Hence my interest in an in-place replacement instead.
;)

Cheers! -Damian
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev