Obvious things I'd like to do that won't break anything: * Abstract out crypto calls, with the eventual goal of moving from openssl to something with a more flexible license. * Test suite. We need one. * Switch the "return -1" cases that really mean "you've got a bug" into calls to assert(). * Since my OR can handle multiple circuits through a given OP, I think it's clear that the OP should pass new create cells through the same channel. Thus we can take advantage of the padding we're already getting. Does that mean the choose_onion functions should be changed to always pick a favorite OR first, so the OP can minimize the number of outgoing connections it must sustain? * Rewrite the OP to be non-blocking single-process. * Add autoconf support. Figure out what .h files we're actually using, and how portable those are. * Since we're using a stream cipher, an adversary's cell arriving with the same aci will forever trash our circuit. Since each side picks half the aci, for each cell the adversary has a 1/256 chance of trashing a circuit. This is really nasty. We want to make ACIs something reasonably hard to collide with, such as 20 bytes. While we're at it, I'd like more than 4 bits for Version. :) * Exit policies. Since we don't really know what protocol is being spoken, it really comes down to an IP range and port range that we allow/disallow. The 'application' connection can evaluate it and make a decision. * We currently block on gethostbyname in OR. This is poor. The complex solution is to have a separate process that we talk to. There are some free software versions we can use, but they'll still be tricky. The better answer is to realize that the OP can do the resolution and simply hand the OR an IP directly. A) This prevents us from doing sneaky things like having the name resolve differently at the OR than at the OP. I'm ok with that. B) It actually just shunts the "dns lookups block" problem back onto the OP. But that's ok too, because the OP doesn't have to be as robust. (Heck, can we have the application proxy resolve it, even?) * I'd like a cleaner interface for the configuration files, keys, etc. Perhaps the next step is a central repository where we download router lists? Something that takes the human more out of the loop. We should look into a 'topology communication protocol'; there's one mentioned in the spec that Paul has, but I haven't looked at it to know how complete it is or how well it would work. This would also allow us to add new ORs on the fly. Directory servers, a la the ones we're developing for Mixminion (see http://mixminion.net/), are also a very nice approach to consider. * Should ORs rotate their link keys periodically? * We probably want OAEP padding for RSA. * The parts of the code that say 'FIXME' Non-obvious things I'd like to do: (Many of these topics are inter-related. It's clear that we need more analysis before we can guess which approaches are good.) * Padding between ORs, and correct padding between OPs. The ORs currently send no padding cells between each other. Currently the OP seems to send padding at a steady rate, but data cells can come more quickly than that. This doesn't provide much protection at all. I'd like to investigate a synchronous mixing approach, where cells are sent at fixed intervals. We need to investigate the effects of this on DoS resistance -- what do we do when we have too many packets? One approach is to do traffic shaping rather than traffic padding -- we gain a bit more resistance to DoS at the expense of some anonymity. Can we compare this analysis to that of the Cottrell Mix, and learn something new? We'll need to decide on exactly how the traffic shaping algorithm works. * Make the connection buf's grow dynamically as needed. This won't really solve the fundamental problem above, though, that a buffer can be given an adversary-controlled number of cells. * I'd like to add a scheduler of some sort. Currently we only need one for sending out padding cells, and if these events are periodic and synchronized, we don't yet need a scheduler per se, but rather we just need to have poll return every so often and avoid sending cells onto the sockets except at the appointed time. We're nearly ready to do that as it is, with the separation of write_to_buf() and flush_buf(). Edge case: what do we do with circuits that receive a destroy cell before all data has been sent out? Currently there's only one (outgoing) buffer per connection, so since it's crypted, a circuit can't recognize its own packet once it's been queued. We could mark the circuits for destruction, and go through and cull them once the buffer is entirely flushed; but with the synchronous approach above, the buffer may never become empty. Perhaps I should implement a callback system, so a function can get called when a particular cell gets sent out. That sounds very flexible, but might also be overkill. * Currently when a connection goes down, it generates a destroy cell (either in both directions or just the appropriate one). When a destroy cell arrives to an OR (and it gets read after all previous cells have arrived), it delivers a destroy cell for the "other side" of the circuit: if the other side is an OP or APP, it closes the entire connection as well. But by "a connection going down", I mean "I read eof from it". Yet reading an eof simply means that it promises not to send any more data. It may still be perfectly fine receiving data (read "man 2 shutdown"). In fact, some webservers work that way -- the client sends his entire request, and when the webserver reads an eof it begins its response. We currently don't support that sort of protocol; we may want to switch to some sort of a two-way-destry-ripple technique (where a destroy makes its way all the way to the end of the circuit before being echoed back, and data stops flowing only when a destroy has been received from both sides of the circuit); this extends the one-hop-ack approach that Matej used. * Reply onions. Hrm.