Some draft notes on migrating Tor's ciphersuites
Watson Ladd
watsonbladd at gmail.com
Sat Dec 18 14:01:04 UTC 2010
One thing that I would like to point out is that .onion addresses will
always contain a public key, and we want to keep them short. This
means ECC (un)fortunately, but apparently DJB has an unencumbered
implementation.
The other thing I would like to note is that when we extend a relay,
we are going to reveal something about the client if we use a protocol
version number that is externally visible to the passing relay. I
don't really see a way around this given that the next relay needs to
know in what format the remainder of the data is in the packet
So I think we also have 2 separate problems here. Problem 1 is this
upgrade, and Problem 2 is future-proofing. Unfortunately they feed
into each other.
What we could do is (depending on how tor responds to unused commands)
is defined EXT_CREAT as packet number 10 which has the format
CircID 2 bytes
10 1 byte
SUITE 1 byte, 0 for this revision.
PAYLOAD fills remainder of packet.
When a client receives indication that its EXT_CREAT was not
recognized it falls back on CREATE. ORs send back a packet that
indicates if they do not recognize the SUITE and the client falls back
to an earlier revision.
It is important that all clients support only 2 methods to avoid
massive fracturing of the anonymous set. ORs probably also should also
do this.
Anyway, that is my 2 cents.
Sincerely,
Watson Ladd
More information about the tor-dev
mailing list