[tor-dev] Fwd: Plan of attack for part (c)

[Watson Ladd <watsonbladd@xxxxxxxxx>]

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@xxxxxxxxx>
Date: Thu, Feb 16, 2012 at 8:03 PM
Subject: Fwd: Plan of attack for part (c)
To: Nick Mathewson <nickm@xxxxxxxxxxxxxx>, George Kadianakis
<desnacked@xxxxxxxxxx>
Cc: Watson Ladd <watsonbladd@xxxxxxxxx>


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@xxxxxxxxx>
Date: Thu, 16 Feb 2012 13:15:58 -0600
Subject: Plan of attack for part (c)
To: "rransom.8774" <rransom.8774@xxxxxxxxx>

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


-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev