[tor-bugs] #18875 [Metrics/metrics-lib]: Consider replacing RelayNetworkStatusVote's getDirectorySignatures() with getDirectorySignature()
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Jun 8 12:17:51 UTC 2016
#18875: Consider replacing RelayNetworkStatusVote's getDirectorySignatures() with
Reporter: karsten | Owner: karsten
Type: enhancement | Status: new
Priority: Medium | Milestone:
Component: Metrics/metrics-lib | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
Comment (by karsten):
Replying to [comment:2 teor]:
Thanks for your thoughts here!
> I think the underlying question here is:
> "What will happen when we stop using SHA1/RSA_PKCS1_PADDING for our
> I would imagine we'll have to sign both SHA1/RSA_PKCS1_PADDING and
SHA256/ED25519(?) for a while.
Probably, yes. I mean, we could also teach all fellow directory
authorities how to verify the new signature scheme and then switch, but it
seems easier to just include two signatures for a while. It would violate
the "Exactly Once" part in dir-spec.txt, but I guess that's easy to
I'd say, for metrics-lib, let's assume it's at least possible that votes
contain more than one signature, even if that has not happened so far.
> I also have a related question:
> What is the "String" key in the current metrics-lib
From the latest Javadocs, that string is "the SHA-1 digest of the
authority's identity key in the version 3 directory protocol, encoded as
40 upper-case hexadecimal characters."
Maybe the better answer is: let's get rid of that string, because it's
confusing and is already contained in `DirectorySignature`, and turn the
map into a list. (See suggestion below.)
> How does it handle signatures from legacy keys?
Uhm, fine question. IIUC, votes only contain signatures made by the
authority's non-legacy key, and consensuses contain both legacy and non-
legacy signatures. So, for this ticket where we primarily consider votes,
this doesn't matter. And consensuses simply contain more signatures than
there were authorities contributing to the consensus.
> I'd suggest passing the algorithm / identity / signing key digest to the
function (if they're not already implicit as part of the
> That way, you can return the appropriate signature.
> Perhaps it's worth having a form of the function with sensible defaults,
like `getDirectorySignatureSHA1RSA()`, which would get the SHA1/RSA
signature from the most recent signing key for that authority.
I think the simpler approach is to return a list of all signatures which
contain algorithm, identity and signing key digest, and let the
application skip over all signatures it doesn't care about. That would be
`public List<DirectorySignature> getSignatures()`, both in consensuses and
Again, thanks for your feedback!
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18875#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs