On 5/7/12 7:49 PM, Beck Chen wrote:
On Mon, May 7, 2012 at 5:13 PM, Karsten Loesing karsten@torproject.orgwrote:
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.
Then is it possible that metrics-db modifies the fingerprint at the same time so that the first #1 would pass?
Right, but when the fingerprint changes, we consider the descriptor as coming from a different relay. If metrics-db wanted to fake descriptors of a known relay and stem only checked #2, stem would be fooled here. With #1 it wouldn't.
Note that for most analyses you'd start with the consensus and only look at referenced descriptors by their SHA digest, which rules out modifications like the one discussed above. But if there's a method in the server descriptor class to check whether it is valid it should check #1 and #2.
Robert may have a more complete list of things that need to be checked in descriptors of all sorts. I just asked him in #2768 for such a list.
Any why would metrics-db try to do this at all?
Well, it wouldn't. But why trust it when you can check yourself?
Best, Karsten