Re: [tor-dev] [tor-assistants] Python metrics-lib

[Karsten Loesing <karsten@xxxxxxxxxxxxxx>]

On 5/7/12 7:49 PM, Beck Chen wrote:
> On Mon, May 7, 2012 at 5:13 PM, Karsten Loesing <karsten@xxxxxxxxxxxxxx>wrote:
> 
>> 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
>>>> 1) a contained fingerprint is actually a hash of the signing key and
>>>> 2) a router signature was created using the signing key.
>>>>
>>>> Verify consensuses using the separate certs.  Verify that
>>>> 1) the fingerprint in a cert is actually a hash of the identity key,
>>>> 2) a cert was signed using the identity key,
>>>> 3) 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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev