On Mon, May 7, 2012 at 5:13 PM, Karsten Loesing <[email protected]>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? Any why would metrics-db try to do this at all? Cheers, Beck
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
