[freehaven-dev] 2/25/2001 meeting notes

[Roger Dingledine <arma@mit.edu>]

1) Free Haven Redesign:

main problem: broadcast

a decentralized network + chords approach may well work better

just as in the first free haven design where we put all the tough parts
into the trust system, are we this time moving all of the challenging
problems into the mixnet?

meeting server -- a way of making it so participants don't need to
publish reply blocks (which can be collected and then cracked via
intersection attacks). think of it like an irc server where people use
their anonymous channels to get to it and then talk to each other from
there. it "connects the pipes".

frequency hopping -- meeting server to agree on which relay to
use? basically show up, negotiate a key and a relay, and then go there.

ideally, we might have a chords-like interface where people register
their 'current location', and so there are no fixed or identifiable
meeting places (and thus no bottlenecks in the protocol).

zks system too complex -- handles all user options/situations. they
focus on a 'good user experience' (they have to; it's a commercial
thing). we just want to develop some infrastructure that can handle
our situation. even (especially) if it's just a back-end.

mixnets aren't secure. neither are we. we just want to be 'better'
than the currently-deployed systems.
specifically, consider defending against what johnb calls the 'lawyer
attack': a lawyer wants to nail you, but he wants to do it without
actually breaking the law or screwing with the evidence directly. so he
would be both passive (get a warrant, listen) and active (make a bunch
of new servers, try to fake you out), but he wouldn't do outright illegal
things. it's a good 'first threat model'.

extensibility is key.

perhaps later add a protocol description language for easier extension --
basically you describe what you want to add and the core parses it and
handles that functionality.

2) the mixnet goals

david molnar doesn't like client-picked paths. yet it seems difficult
to get a reasonable alternative. one alternative is a large permutation
computation. but that seems unintuitive and not 'simple' to implement. but
the great thing is, we can combine the two notions later -- just treat
one of those snazzy permutation clouds as a single mix node.

getting adam smith (eg) to analyze. i bet if we build something, people
will come out of the woodwork to take a look at it.

there are a number of people out there (smart coders, smart designers,
and smart crypto people) who can help us out on this. we should be sure to
keep that in mind as we're going. but as with all free software projects,
the trick is to do the work and let other people help; not to hope that
they'll do the work.

i'll send a more detailed set of goals for the mixnet in a separate mail.

3) Red Rover. I think the current concensus is that the overall
goals seem good, but the approach may not be the right one to take at
all. Peer-to-peer is a nice notion in that it will garner support and
publicity, but that doesn't mean it's the best approach from a technical
point of view. We should try to get more info from Alan and Oxblood, and
see where it goes. In the meantime (independently), Rachel is looking at
"steganography in big brother countries" papers with the intent of trying
to find a masters thesis in it.

4) IEEE thing. See previous post; I think we're going to pass on it,
unless I suddenly develop a free week (ha ha).

5) Mixnet accountability paper. We didn't really get to this in the
meeting time; we'll cover it over email.