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