Re: reader anonymity (Re: [freehaven-dev] eternity USENET comparison)

[Roger Dingledine <arma@mit.edu>]

I'm actually leaving the country in 2 hours for about 3
weeks, and will be totally out of touch. But I finally dredged
up time to read this thread and figured I should lay out some
of my responses.

On Sat, Jun 17, 2000 at 04:26:03PM -0400, Adam Back wrote:
> dmolnar wrote:
> > > > - Eternity USENET actually provides pretty aggressive
> > > > Reader Anonymity: consider how hard it would be to track
> > > > down which internet users read a given alt newsgroup post.
> > >
> > > I don't need to be able to tell who's reading it to violate reader
> > > anonymity; I just need to be able to, given two people one of whom is
> > > a reader, pick the reader substantially more than half the time.  That
> > > is, I just need to be able to tell if Bob is a reader, given some Bob.

Free Haven does not provide this sort of "general reader anonymity"
either -- we simply say that given two *readers* Alice and Bob one of
whom read a given document, we can't figure out which one of them read
it. We make no claims about keeping (in our case) people from figuring
out if they're sending mail to remailer nodes or receiving it from them.

I should stress that by 'figure out', I mean distinguish at all. We are
concerned not with whether somebody can prove something, but rather with
whether they learn enough information to even suspect. Governments that
require proof before they take action are quite pleasant relative to
organizations that want to break kneecaps until their problems go away.

This is a major difference in approach from what projects like freenet
seem to be taking. They claim that if they frob the TTL decrement function
a bit, then they make it impossible to tell for certain -- so their users
are safe. Riight.

> > The moral of the story seems to be that we need to break down "reader
> > anonymity" and "reader" some more. There seem to be several different
> > notions lurking here.
> 
> Yup.  I was about to reply that it depends what type of reader 
> anonymity one is considering.
> 
> For reader anonymity there are a whole bunch of attacks which an
> attacker might want to execute:
> 
> (1) document readership - determine readers of given document
> (2) confirm reader suspicion - confirm suspicions about whether a 
> given internet user read a given document
> (3) user base - get a list of users of the service
> (4) confirm use - confirm suspicions about whether a given internet 
> user uses the service

Given my comment above about prove vs suspect, I would argue for
a rewording of these if we want to adopt them into the Free Haven
context. And I think if we formalize it further, it might turn out
that there are variables we didn't consider, such as #2: if we have
a user and he does a bunch of queries only every three months right
after a given document is renewed, does that tell us anything?

Are there comparable long-term-timing attacks on Free Haven? (probably)

> Brian seemed to focus on confirming readers of the document.  
> Depending on the software configuration, and how powerful the 
> attacker is, eternity USENET can defend against all of those 
> criteria.
> 
> There are a number of different configurations of the eternity USENET 
> software:
> 
> (a) users of public proxies (proxy running SSL, local newspool)
> (b) users of public proxies (proxy not running SSL, remote newserver)
> (c) users of local proxy client (local newspool, or local newsserver)
> (d) users of local proxy client (remote newsserver)
> 
> Attack (1) finding document readership requires host compromise
> for config (c), and is expensive for (d), but relatively cheap for (b), 
> and not that hard for (a), as SSL doesn't hide response size.
> 
> Attack (2) confirm reader suspicion means first doing attack (4), 
> which itself may require host compromise in config (c), but otherwise 
> is relatively easy to achieve by monitoring the targetted users
> connections.
> 
> Defending against (3) finding user base is pretty hard to protect 
> against without a prexisting massively distributed anonymous 
> broadcast channel, and I don't  think any other currently fielded 
> or proposed systems other than Eternity USENET stand a chance of 
> doing this.  This is why I say Eternity USENET provides strong 
> reader anonymity.

We've got some more terminology issues here. I'll analyze Free Haven
in this context:
If you mean 'find server base', it's easy -- become a server and
you'll learn about the others after a while.
If you mean 'find reader base', it's much more difficult. Since each
read operation uses a unique (one-time) remailer block and key, there
is no linkability between reads, even from the perspective of the
server (this is our so-called perfect forward reader anonymity -- I
don't think eternity usenet gets this, because there is correlation
between IP addresses?)

Thus you'd have to compromise the remailer chain for a given read --
in advance -- in order to learn the identity of that reader.

On the other hand, just to try to throw a wrench into my own argument:
what if you compromised (or ran) one edge (as opposed to middle-man)
remailer node? Two? Three? Could you tell that what you were delivering to
people was Free Haven material? (We keep debating about whether to put a
cleartext "This is from Free Haven, sorry for the spam if you didn't want
this" at the top of messages.) This doesn't allow you to hit a given user,
because he'll be generating an (apparently) arbitrary remailer path each
time, but it could allow you to build a list of readers.

> Eternity USENET achieves this for the proportion of users using 
> configuration (c).  There are probably 100s of thousands to 
> millions of users with the existing network infrastructure to be 
> config (c) users.  The resources required to obtain an exhaustive 
> list of users (3) for  users using configuration (c) are massive 
> compared to other systems with fielded nodes in the low tens or 
> hundreds.

Agreed. But again, exhaustive is not what matters. 'Some polynomial
fraction of' is a very successful attack, from a theory point of view.
From a reality point of view, "more than a couple hundred" may well be
sufficient to kill them all and make a big press incident, regardless
of how many users there are total.
 
> The success of attack (4) against config (c) depends on whether
> the attacker can compromise host security.  For other configs
> is relatively easy.
> 
> Adam

And now, I'm going to go pack and flee the country. Have fun writing
the papers, guys. :)

Thanks,
--Roger