[freehaven-dev] Some comments

[David Hopwood <hopwood@zetnet.co.uk>]

-----BEGIN PGP SIGNED MESSAGE-----

My comments on some stuff:

> In the observe phase, we assume that raters make queries independently of
> each other by sending test messages to individual MIXes. If the test
> message survives, the rater should \emph{report} that the MIX is good. If
> the test message is dropped, the rater should report that the MIX is bad.
> We call a report \emph{honest} if it issues from a query and the report
> and query agree. We further call a report \emph{correct} if the report
> identifies an adversary-controlled MIX as a bad node or a good MIX as
> good; a report may for example be honest but incorrect if a good MIX
> drops a query (although in this example, $p_{good} = 0$, so honest but
> incorrect  reports will not occur).
> % XXX how can a good MIX drop a query if p_good = 0?
> % it can't - I was referring to in general. -DM

Does it matter whether reports are correct or incorrect by the above
definition? I thought that we were only trying to measure performance,
not intent - so a MIX that drops a query is by definition "bad", regardless
of whether it intended to drop it.

I suggest deleting from "We further call...".


> ... We must contend with imperfect knowledge of
> bandwidth (edge capacity) and the costs associated with an edge.  We
> may approximate the cost of an edge $(s,t)$ as equal to its
> destination's probability of failure $p_f(t)$; still, reputation
> measurements may lag behind current network state, and users should
> % This isn't clear. Do you mean continually updating paths causes a
> % security problem, or just that it's inconvenient? --DH
> % Don't we talk about this elsewhere?  Once you pick a path, you
> % want to stick with it for a while, a la Crowds reason -mjf
> not be continually updating MIX paths in order to preserve better
> anonymity coverage.

Crowds isn't a mix-net - AFAICS the reasons for using static paths in
Crowds don't apply to mix-nets. Section 5.3.2 of the Crowds paper says:

# The reason [for not using more dynamic paths] is that the probable
# innocence offered by Theorem 5.2 vanishes if the collaborators are
# able to link many distinct paths as being initiated by the same jondo.
# Collaborating jondos might be able to link paths initiated by the same
# unknown jondo based on related path content

But in a mix-net, unlike Crowds, all content is encrypted in such a way
that intermediate nodes cannot read it, or link it with other messages.

# or timing of communication on paths.

In a mix-net, again unlike Crowds, batching is used to prevent this.

# ... collaborating jondos have a higher probability of receiving each
# path initiation message (i.e. the first request on the path) from the
# initiator of the path than from any other individual member (see the
# proof of Theorem 5.2). Multiple paths initiated by the same users's
# jondo therefore pinpoint that jondo as the one from which the
# collaborators most often receive the initiating messages.

This argument is specific to how Crowds attempts to conceal the
sender/initiator; in a mix-net, there is usually no attempt to conceal
that a message is the first on the path (i.e. came from a sender rather
than a node); instead the anonymity relies on the fact that intermediate
messages are indistinguishable. If I understand correctly, Crowds is
much more similar to Freenet than it is to a mix-net.

- -- 
David Hopwood <david.hopwood@zetnet.co.uk>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBOrbudTkCAxeYt5gVAQGHWgf8C+DdC0cZYEb2P+HgdSKgKU+Ea6c7bzIu
rR5iS5Jzek86IPhDHfE//OAKFwGeqCr1nb1chDBSthmGmz/mA7hvyz6PaEinZpF3
Vj8UqKCvtP2Wl8IR+TFeuhhlgX8vmQvEMFCJj1gKhMNLCUS6Csywdb1/DztzxCHS
1ciLHCRBI5V2sluYddgy1M4EuCom3SBHQG77JY0ezLpOYBsrtaTXHlWDoLHLFJws
sC+K5zzGC3TUbylUTwDBmu5FfuiBu5GmUkJnHwqA8XrnwSLBh24US2FxMdg50J8W
e5mCC5XDROIE03cQkACzyrOp+CQqcxT7c3rvdMr7+BKC8UxUgSqMTQ==
=ibkh
-----END PGP SIGNATURE-----