I'm forwarding the following 2 messages about work that I'm thinking about doing to the Tor code to pave the way towards multiple cryptographic methods for route extension. Feel free to comment critically on the proposed design, especially if it impacts areas you are working on or know about. If you have alternative ideas that's also good. Sincerely, Watson Ladd ---------- Forwarded message ---------- From: Robert Ransom rransom.8774@gmail.com Date: Thu, Feb 16, 2012 at 8:03 PM Subject: Fwd: Plan of attack for part (c) To: Nick Mathewson nickm@torproject.org, George Kadianakis desnacked@riseup.net Cc: Watson Ladd watsonbladd@gmail.com
Forwarding to Nick and George (who has looked at the crypto code before), because I'm not going to be able to think about this much today.
This sort of discussion should probably be on the tor-dev mailing list.
---------- Forwarded message ---------- From: Watson Ladd watsonbladd@gmail.com Date: Thu, 16 Feb 2012 13:15:58 -0600 Subject: Plan of attack for part (c) To: "rransom.8774" rransom.8774@gmail.com
Dear Robert,
I've come up with the following sketch of a plan to handle the obstacle of crypt_path_t to multiple negotiation methods. It isn't actually the problem. The problem is the crypto_dh_t * dh_handshake_state. I propose defining an enum handshake_methods_t and a handshake_state that looks like typedef struct { enum method; union { crypto_dh_t *dh_handshake; } u; } handshake_state;
The extend_info_t structure will need to be modified to point to a list of similar handshake_key structures, probably in the form of a linked list. This involves modifying the functions that allocate extend_info_t's, of which thankfully there are few.
Once this is done we can genericize the onion_skin functions by making new functions which essentially consist of a switch statement on the value of method. One unresolved issue is selecting the method to be used when multiple methods are available: I'll probably just take the first handshake_key and complain if it doesn't match what the handshake_state should be when processing the response. Servers are a trickier issue, but if they have a list of handshake_keys we can sort through it to find the key that matches a particular method, and rely on the new CREATE2 cell mechanism to tell us what the method is.
Are there requirements for a fix that this idea doesn't meet? Any hard decisions that I've made the wrong call on? And thank you very much for taking the time to help me through working with the tor code.
Sincerely, Watson Ladd