On 2011-11-01, Roger Dingledine arma@mit.edu wrote:
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 nextnode 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.
I suggest gluing the fingerprint-extraction function to the identity-key signature cryptosystem in our protocols. So, instead of hashing 2048-bit RSA keys in multiple ways, we would have rsa2048-sha256 for 2048-bit RSA keys used to sign SHA-256 hashes *and* hashed into fingerprints using SHA-256, and we might also have rsa2048-tiger for 2048-bit RSA keys used to sign Tiger hashes and hashed into fingerprints using Tiger.
Curve25519 public keys do not need to be hashed to form fingerprints -- the keys themselves are shorter than the output of any hash function we would consider using. (Yes, I know Tiger has a 192-bit output. We wouldn't consider using it.)
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.
They won't work. I suggest base32-encoded 255-bit (sīc) hashes or public keys (51 characters long).
It may well be fine to say that the feature dies in the migration, but we should actively decide it rather than overlooking it.
We need to support some way to extend circuits to a specified exit node without requiring a controller that reimplements Tor's full path selection algorithm.
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.
No. We will only use fingerprints of identity keys for TLS-based link protocols.
Link specifiers for our UDP-based link protocol will contain a link-authentication public encryption key, and the CREATE cell that causes a relay to open a UDP-based link will be sent encrypted to that public key in the packet which opens the link. (Yes, I know we can't get forward secrecy for anything we send in that first packet encrypted to a non-short-term public key. We don't need forward secrecy for a CREATE cell.)
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.
We discussed how to handle multiple crypto protocols earlier this year. Each relay publishes an ordered list of the protocols it likes for each protocol slot; the consensus contains a set of currently approved protocols for each protocol slot; each client uses the first protocol in the relay's list which (a) the client supports and (b) is listed in the consensus as ‘approved’, unless the user specifically configures the client to use a custom set of protocols. The approved-protocol set in the consensus can both protect the anonymity of clients which support new protocols and disable old protocols if they break.
Robert Ransom