Re: [tor-dev] Draft sketch document with ideas for future crypto ops

[Roger Dingledine <arma@xxxxxxx>]

On Mon, Oct 31, 2011 at 09:25:58PM -0400, Nick Mathewson wrote:
>   The point of this document is to discuss what crypto we ought to be using.

Thanks Nick!

>     - To make sure that the extending node is talking to the right next node
>       when sending an extend cell.
> 
>   The new extend cell format needs to allow the client to tell the
>   extending node about some identity for the destination node that the
>   extending node will be able to understand.  This is a capability of
>   the extending node that the client needs to be able to check. (Also,
>   the extend cell needs to hash that identity in a form the extending
>   node can understand, but that's a fingerprint issue.)

Right now microdescriptors don't have any identity key in them. It would
seem that Alice never needs to remember the identity key for the relays
she uses at all. (She learns the fingerprint of the identity key from
the microdescriptor-flavored consensus, and if she does a handshake with
the relay she can learn its identity key while making sure it hashes to
the right thing, but otherwise she doesn't use or remember it.)

This is fine until we get to your sentence about Alice needing to know
how to hash the identity in some other form.

>   a  When representing them in the UI, we should
>   use the notation %b64, where b64 is a base-64 encoding, omitting the
>   trailing =s.

Another use for identity keys that we left out of the list is the dot-exit
notation. I don't think base64 domain names will work.

It may well be fine to say that the feature dies in the migration,
but we should actively decide it rather than overlooking it.

> 3.4. Implications for EXTEND cells
> 
>   As mentioned in 3.3, when a client Alice tells node Bob to extend
>   to node Carol, she needs to give Bob a fingerprint for Carol that Bob
>   will understand: one where Bob understands the digest algorithm, and
>   understands the identity key type.
> 
>   There are two ways we can do this:
> 
>     1) Alice's EXTEND cell contains every fingerprint for Carol that
>        Alice knows about.  Bob treats the cell as valid if every one he
>        can verify is correct.
> 
>     2) Alice knows which fingerprint types Bob understands (either via
>        his version, or something else in his directory info).  She
>        selects a fingerprint for Carol using the best one of these
>        types.
> 
>   The first seems more robust to me, if we have space for enough bytes.
>   If we proliferate too many types, though, we'll need to do the second.

The first seems more prone to partitioning worries to me. If different
clients know how to handle different fingerprints, and the anonymous
client tells us which fingerprints it knows how to handle, that could
be bad news. Unless we're planning to just have Alice stick in all the
blobs that she thinks are fingerprints, whether her Tor version knows
how to read them or not? That could work.

--Roger

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev