On Sun, 19 Dec 2010 08:46:13 -0500 Watson Ladd <watsonbladd@xxxxxxxxx> wrote: > On Sat, Dec 18, 2010 at 10:34 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote: > > 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 > > minimum. My current plan to minimize partitioning of the client anonymity set is: * The directory authorities should specify lists of cryptographic primitives (identity key signature systems, circuit-extension handshakes, circuit ciphersuites, etc.) that relays are permitted to support in the consensus. * The directory authorities should specify lists of cryptographic primitives that clients should consider using in the consensus. * Each relay should specify lists of cryptographic primitives that it is willing to use in its descriptor, ordered by the relay's preference (e.g. the relay puts its favorite primitive in a list first). * A client should select the first cryptographic primitive in a relay's list that (a) the consensus recommends that clients use, and (b) the client supports. * The Tor developers should not introduce new cryptographic primitives between two stable releases in the same branch. The Tor client will need to support torrc options that override the lists of recommended cryptographic primitives in the consensus in order to allow testing of not-yet-recommended primitives on the public Tor network, but the manual page will need to warn explicitly that setting those options will harm a Tor user's anonymity. This plan relies on the directory authorities not recommending a new cryptographic primitive until a large fraction of Tor clients support it. > 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 think that if we follow the plan above, we don't need to limit the number of cryptographic primitives of each type in order to preserve the client anonymity set. It's more important to have at least two cryptographic primitives of each type implemented, even if we expect that few relays will prefer one of them, in order to ensure that we get the APIs for each primitive right. Robert Ransom
Attachment:
signature.asc
Description: PGP signature