Re: [freehaven-dev] rfc: defining anonymity

["Michael J. Freedman" <mfreed@MIT.EDU>]

>Many services rely on sheer volume of servers, each containing the data,
>to dissuade organizations from attacking any given server for possessing
>the data. However, this approach does prevent large corporations from

"prevent" is a rather absolutist word.  I would suggest "dissuade"

>participating in these questionable networks, due to liability and
>reputation concerns. Also, there may be some circumstances, such as the

Likewise, "questionable" is rather biased...

>
>\subsubsection{Anonymity vs. Pseudonymity}
>
>anonymity means that that side of the transaction really has no 'location'.
>often this is characterized by a 'pull' type of operation, eg on a
>bulletin-board system or some other publication medium like the web.

I'm not exactly sure what is being said here.  Are you refering to the
operation where a user merely looks up a web page?  "that that side of the
transaction"  (you are referring to author anonymity?  or what?  the "side"
isn't clearly specified, to me...)    Even if this is the case, why is this
"anonymous"?  I download something from the 'net, I know the IP address of
the web page, likewise, the web page knows my (the person browsing) IP
address when I connect.  Simple environment variables...On a BBS, the
administrator knows explicitly the telephone number of the person calling
up...(and probably can determine what section of the BBS they are currently
using).


>pseudonymity means there is a location associated with the person, even
>if this location is a 'one-use' type of thing. there's one-time pseudonymity
>which is that, and then there's persistent pseudonymity where you use the
>same location across multiple transactions.
>
>free haven uses pseudonymity for readers and for servers. we could
>theoretically support anonymity for authors. that really isn't speced
>out yet. (we should fix that.)

Is the definition of author being the servnet node which puts a document
into the servnet, or the actual person who desires the document to be
placed into it?  If the latter, then its control is somewhat one
abstraction layer above us.  To my understanding, we are leaving the means
of submission from person -> servnet node as out of the spec.  Namely,
those runnings servnet nodes can only be doing for themselves;  or, they
can even be running some front end web app with which people can purchase
storage.  

Again, if the latter type of authorship, it is (somewhat) out of our hands.
 If the former, then how is this much different than a trade...the system
really shouldn't see anything different then a (whole lot of) trades
occuring during publishing...in which case it seems to fall also under
pseudonymity.

>
>\subsubsection{Computational vs. Information-Theoretic Anonymity}
>
>One of these issues is the notion of how protected a given address is:
>does it rely on computational complexity to protect its anonymity (e.g.,
>a reply block address on a conventional mixnet), or does it use
>some other technique to make the address unknowable even in the face of
>a computationally powerful adversary?

Thesis, anyone?

>\subsubsection{Perfect Forward Anonymity}
>
>perfect forward secrecy means that after a given transaction is done,
>there is nothing new that the adversary can 'get' to help him decrypt
>the transcript.
>similarly, perfect forward anonymity is the notion that after a given
>transaction is done, there is nothing new that the adversary can get
>that can help him identify the location or identity of either of the
>communicating parties.
>
>this can be phrased as a game: if A is talking to some unknown party B,
>can our adversary E distinguish with better than even probability between
>whether A is talking to B or A is talking to C?
>
>from here, we can define classes of adversaries such that some classes
>can beat us in some circumstances, and some can't.
>
>for instance, some adversaries might be able to watch the link between
>them, some might be able to frob with the link as well. some might be
>able to observe the private state of A and/or B (that is, data which is
>internal to the nodes but doesn't get sent over the network). maybe some
>could even modify private state.

Oooh....sounds like some more things should be written into threat.tex.
Dave, you really might want to start adding your posts to freehaven-dev
into that source.  It shouldn't take all that long, and would greatly
centralize some descriptions / discussions.

>subtle attack to watch out for: since we're talking about anonymity,
>there are issues we have to address that we don't consider when we're
>dealing with encryption. for instance, if B is running a server at his
>company, what about the cached data in the NIDS down the hall? is that
>part of B? because it can certainly help to distinguish...  what if one
>of the packets in the transmission got sent off course, and 120 seconds
>later an ICMP destination unreachable packet returns to B, with its
>data segment an exact copy of one of the packets that was sent to A?
>Is 120 seconds negligible? what isn't negligible?

Well, the ICMP packet should only be able to ping B if it is the first
(last) hop in the mixnet route.  As headers are cyclicly stacked (at least
with Mixmaster), the previous headers are unreadable by the next stage in
the mixnet (and thus, only making a full circle, revealing the source, when
reaching the destination).    So, for a multi-hop mixnet message, is a ICMP
message that bad if it might suggest the first hop from B into mixnet
(which a listener on B's line would be able to determine anyway?)


>if we want to address adversaries, it should probably be its own
>subsubsection.
>
>\subsubsection{Social Engineering}
>
>bear in mind that no matter how cool your anonymity is, if you sign
>your name to your document, you lose. also, more subtle attacks such
>as word choice correlation or writing analysis might yield clues that
>allow better than even chances of guessing. all of the above models
>are based on the idea that a given document is a random distribution of
>bits. [is that a strong enough requirement? is that too strong?]

a la "Never underestimate people's own stupidity?"
I think this is quite beyond the scope of our analysis...

Hope it [my rambling] helps [in the slightest]...
--mike



---------------------------------
  Michael J Freedman

Mail:  mfreed@mit.edu
Web:     griffen.mit.edu
Phone:    617.225.9381