<div class="gmail_quote">On Mon, May 7, 2012 at 5:13 PM, Karsten Loesing <span dir="ltr"><<a href="mailto:karsten@torproject.org" target="_blank">karsten@torproject.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On 5/6/12 3:36 AM, Damian Johnson wrote:<br>
> First I'd like to make sure that I'm clear on what we're trying to do.<br>
> The javadocs for VerifyDescriptors [1] says that it...<br>
><br>
>> Verify server descriptors using the contained signing key.  Verify that<br>
>> 1) a contained fingerprint is actually a hash of the signing key and<br>
>> 2) a router signature was created using the signing key.<br>
>><br>
>> Verify consensuses using the separate certs.  Verify that<br>
>> 1) the fingerprint in a cert is actually a hash of the identity key,<br>
>> 2) a cert was signed using the identity key,<br>
>> 3) a consensus was signed using the signing key from the cert.<br>
><br>
> Honestly I'm not yet sure what most of this means. The first #2 is<br>
> simply checking that the descriptor content can be verified using the<br>
> router-signature and signing-key, right?<br>
<br>
</div>Yup.  But you also need the first #1, or metrics-db could modify server<br>
descriptors at will, put in its own key, and re-sign the descriptor with<br>
that key, and stem would think everything's valid.</blockquote><div> </div><div>Then is it possible that metrics-db modifies the fingerprint at the same time </div><div>so that the first #1 would pass? Any why would metrics-db try to do this at</div>

<div>all?</div><div><br></div><div>Cheers,</div><div>Beck</div></div>