On 5/6/12 3:36 AM, Damian Johnson wrote:
First I'd like to make sure that I'm clear on what we're trying to do. The javadocs for VerifyDescriptors [1] says that it...
Verify server descriptors using the contained signing key. Verify that
- a contained fingerprint is actually a hash of the signing key and
- a router signature was created using the signing key.
Verify consensuses using the separate certs. Verify that
- the fingerprint in a cert is actually a hash of the identity key,
- a cert was signed using the identity key,
- a consensus was signed using the signing key from the cert.
Honestly I'm not yet sure what most of this means. The first #2 is simply checking that the descriptor content can be verified using the router-signature and signing-key, right?
Yup. But you also need the first #1, or metrics-db could modify server descriptors at will, put in its own key, and re-sign the descriptor with that key, and stem would think everything's valid.
If so then this sounds like a good place to start since it's entirely self-contained within the descriptor and just involves implementation and testing of...
https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/descriptor/server_des...
Sounds good.
For other descriptors than server descriptors, you may want to have a similar method that accepts the signing key. In the case of certs and consensuses you'd have an is_valid() method for certs, a getter in the cert class to obtain the signing key, and an is_valid(signing_key) in the consensus class.
Best, Karsten