Some draft notes on migrating Tor's ciphersuites
watsonbladd at gmail.com
Sun Dec 19 13:46:13 UTC 2010
On Sat, Dec 18, 2010 at 10:34 PM, Nick Mathewson <nickm at freehaven.net> wrote:
> On Sat, Dec 18, 2010 at 9:01 AM, Watson Ladd <watsonbladd at gmail.com> wrote:
>> 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.
> Actually, the fallback mechanism probably isn't even needed: remember,
> the client has a descriptor for the servers that it wants to extend
> from and to, so it knows which keys and ciphersuites the target server
> supports, and which extend protocols the origin server supports.
Looking at the documentation I see the directory is extensible whereas
what is on the wire is less likely to be.
> You're right that it's important to limit partitioning opportunities
> in any protocol revision; I tried to go over that in section 2, but we
> shouldn't assume that I've said the last word on this. We should
> continue to look for ways to revise and improve whatever we come up
> with to get the partitioning and other undesirable things down to a
One way is to be very conservative in suite choices so we don't have
to change them that often. I'm going to also go out on a limb and say
that we also want a crypto API like NaCL that lets us just say
enciphered=encrypt(key, unenciphered) and doesn't force us to worry
about padding or modes because this is a much simpler abstraction
layer and so offers less opportunity for mistakes that could threaten
security. I'll put together a demo program sometime to demonstrate
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin
More information about the tor-dev