On Fri, 31 Dec 2010 22:28:41 -0500 Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote: > On Fri, Dec 31, 2010 at 4:17 PM, Robert Ransom <rransom.8774@xxxxxxxxx> wrote: > > 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. > > This should probably incorporate allowable key sizes. We don't want > some twit generating 16384-bit identity keys just to slow down all the > clients, but we also don't want somebody using 512-bit RSA keys. Yes. > > * 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). > > Hm. If this involves multiple onion keys, this can potentially bloat > server descriptor sizes; we should consider carefully how we can avoid > that. Perhaps there should be an upper bound on how many onion keys > you can advertise. That may be a good idea, but I expect to allow only one or two types of handshake-authentication key (my term for the onion key). > > * 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. > > Hm. This puts the onus on relay operators of picking the best > primitives. I'm not sure that's such a great idea. Perhaps the > client should pick whichever method supported by both the client and > the relay that the *consensus* recommends first. No -- this puts the burden on the directory authority operators to forbid all 'bad' primitives, and puts the burden on Tor to measure the performance of each primitive on a relay and list the *fastest* primitive on that relay first in its preference list. I expect that all relays will choose the same circuit-handshake protocol and primitives, and we can turn off the rest. However, I want to make sure that relays running on processors with hardware AES support can continue to use AES, while allowing other relays to choose Salsa20. (I am assuming that we will have a portable AES implementation immune to side-channel attacks included in Tor.) > > * 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. > > One thing we will need to think about here is the risk of having > seldom-used code. Remember the time that GPG had broken ElGamal keys > for ages, and it went unnoticed since almost nobody used ElGamal keys? > (CVE-2003-0971) More code does come with more risk. We clearly will need to test the cryptographic code heavily, both as part of Tor and separately. > > 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. > > I am a little skeptical that it will turn out to be quite this simple > once we design it, but at this point I think the easiest way to see > whether we can get away with a good design with all the properties we > want is to just try to make one, and see how it works out. Robert Ransom
Attachment:
signature.asc
Description: PGP signature