1. Ciphers: AES and alternatives
    * AES is the only still viable piece
    * Some don't like AES because it's not fast for results. Faster
      ciphers are available, and some people are in favour of Salsa or the
      ChaCha variant of it.
    * No eliptic curves in use
    * The handling of ENCRYPT_CELL in relays is largely problematic, due
      to AES-CTR and the Replay Attack.
    * Node identity is still tied to RSA 1024
2. Public Key Exchange
    * DH is too short.
3. Hash Functions
    * SHA1 is definitely showing its age.

In each case, revision of protocol choice and better design is needed.

Problems:
  * Keys are too short
  * Process is to slow
  * Security proof of this process is fragile
  * Relay algorithm does not protect integrity

Options:
  * Would like to use newer version of TLS, which also now support
    implementations of elliptic curves.
  * Earlier versions of TLS don't support renegotiating, so later versions
    out never used DTLS. Even though DTLS would technically work well, the
    first problem is that no one but the authors have evaluated it, and,
    second, no one uses it.
      ''Later that night, nickm did a cute "proof" for why Tor should not use
      DTLS. It goes like this:''
            1. [https://www.google.com/search?q="we+use+https" Google for "We use HTTPS"]
               Results: ~1,440,000
            2. [https://www.google.com/search?q="we+use+ssl" Google for "We use SSL"]
               Results: ~1,040,000
            3. [https://www.google.com/search?q="we+use+tls" Google for "We use TLS"]
               Results: ~483,000
            4. [https://www.google.com/search?q="we+use+dtls" Google for "We use DTLS"]
               Results: 6,790. Three of the top ten are links to [https://twitter.com/nickm_tor/status/200956863746019329 nickm talking about how no one uses DTLS].
  * Move to anything eliptic
       a. Bernstein's curve 2559
       b. Or P256
       c. Fedora will not ship eliptic curve stuff, not confident it's not
          patent-encumbered. Patents could be problem, but they are largely
          probably invalid.
  * Large block ciphers
       a. Large block ciphers are even slower than what we're currently
          using.
       b. CBC is even worse than CTR -- it never recovers from errors, making
          it difficult to use.
  * Trying to come up with replacements
       a. Choice of primitives vs. design of protocols
       b. Problems with hop-by-hop auth (as opposed to end-to-end. puts a
          limit on path length, leaks path length on final hope).
       c. Designs could be pluggable, but could lead to some paths being
          undetected.

1. How can we get this plan evaluated by enough people to make good
   decisions?
2. All the things Tor doesn't do and doesn't need to do, see if folks
   can come up with a reason why its good.
3. Need feedback on proposals. Cryptographers and experts preferrably, the
   plan so far is to ask the advice of Patterson, Ian Goldberg, Gunman, John
   Kellis, Bernstein, and others in the community. We could inquire into
   their potential interest in coauthoring a paper on a new protocol.
4. Nick sends all open issues to the list onece a month, but people have
   serious trouble keeping up with the volume and scope of the lists anyway.

* Deploy better crypto by end-of-year
* Steven working on top 10 things that have changed in Tor. Nick will work
  on it with him. Need concrete date.