Re: OR partial todo file

[Andrei Serjantov <aas23@hermes.cam.ac.uk>]

> > Ok, well if you have started a serious design thread, I will continue.
>
> We've got OR code that works and seems robust to basic use. Now's
> the time to figure out what features we actually want, and how hard
> they'll be to get.  Like you and Matej, I'm not happy ignore traffic
> confirmation attacks. I want to make this thing as secure as we can,
> with modern approaches.

Agreed. Think about the rough numbers I proposed in the previous mails and
let me know what you think. (Or do you think they are just too
arbitrary?)

> At the same time, though, I recognize that currently low-latency
> designs are more vulnerable to traffic analysis/confirmation attacks than
> high-latency message-based designs. That's the whole reason we started the
> Mixminion project. You guys (at least Andrei, Paul, Matej) should go read
> the minion-design document at http://mixminion.net/, because it brings
> up a lot of issues that the current onion routing designs don't even
> realize are problems. Specifically, consider sections 3.1, 4.4, and 5.

The above URL does not point to anythign sensible for me. I vaguely
remember the Mixminion design, in particular the tagging attacks issue.
Though I will make every effort to reread the above document when it
become available.

With regards to tagging attacks, OR is resistant to tagging by the active
network attacker, but is vulnerable to compromised mixes tagging. I think.
Maybe this is wrong -- what do people think.

> > > * Add autoconf support.
> > >   Figure out what .h files we're actually using, and how portable
> > >   those are.
> >
> > You are replying on glibc 2.2, as I discovered while trying to install it
> > on an old machine...

> I shouldn't be. Not much, if I am. What needed glibc 2.2?

Ok, slightly confused. The previous code which was in the cvs before you
sent the tar round had a line like this in the Makefile in common/

log.o: /usr/include/_G_config.h /usr/include/wchar.h

wchar.h is not in glibc 2.1

The new one does not seem to rely on this. But I'd need to check.

> > Do you really care that much about who the connection goes to?
>
> Not much for web traffic; but perhaps quite a bit for mail traffic.
> Running an open exit relay for mail traffic is a good way to get a whole
> lot of abuse complaints. Without firm support from your ISP, your node
> will disappear quickly.

Fine. I expected you to say something like this.

> > > * We probably want OAEP padding for RSA.
> >
> > Don't understand.
>
> Without oaep, things encrypted with RSA can be modified but still
> accepted. I need to look at the protocols we use more to decide if this
> opens up any vulnerabilities. I noticed that we don't have integrity
> hashes in very many places; this can open us up to tagging attacks,
> among others.

Yes... I noticed this as well. (The hashes issue). What is OAEP, though?
Tagging attacks by compromised OR's need to be thought about.

> I would like to encourage you guys to peruse the mixminion archives,
> at http://archives.seul.org/mixminion/dev/, and then join the
> mixminion-dev list (send mail to majordomo@seul.org with a body of
> 'subscribe mixminion-dev'. These projects are very similar, and many of
> the pieces (such as directory servers) can be entirely shared between

Very true.

> them. I'm going to be splitting time between them, but at this point
> I'm more hopeful that Mixminion will be a secure thorough system that
> people should actually use. It's an easier problem than onion routing,
> so we figured we'd tackle it first and gain some experience -- and I
> still plan to take that approach.

With OR because there is no currently deployes system (unlike Mixmaster) I
feel we can compromise a little. For instance, I have no opinion between
securing compromised OR tagging or leaving it in this iteration of the
design.

I am stuffed (as usual!) in terms of time at the moment... Should get
better in a few weeks.

A.

------------------
Andrei Serjantov
Queens' College
Cambridge CB3 9ET
http://www.cl.cam.ac.uk/~aas23/