Re: anonymity and trust

--===============0992327810==
Content-Type: multipart/signed;
  boundary="nextPart1902811.UMAPPn223s";
  protocol="application/pgp-signature";
  micalg=pgp-sha256
Content-Transfer-Encoding: 7bit

--nextPart1902811.UMAPPn223s
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

More appropriate for tech. More comments below.

On Tuesday 15 Feb 2011 17:10:18 mark wrote:
> A high level and somewhat naive approach to this complex topic...
>=20
> First, what's anonymity in our context?
> It means exchanging information without anyone knowing who it is who is
> sending and requesting said information.
>=20
> The principle idea how to achieve this is to use an intermediary who
> sends and receives information on your behalf. That way the other end
> never knows your identity. Even a plain http proxy does that.
>=20
> But we haven't solved anonymity yet. We only shifted the problem to the
> "anonymity provider", our messenger. He knows our identity and so does
> everyone who compromises him. The anonymity provider can make it
> "harder" (for others...) to be compromised by using cryptography, not
> storing logs, being located in several offshore locations and by
> relaying traffic over multiple servers internally that all needed to be
> compromised in order to retrace the information back to "you".
>=20
> But that's still not good enough. We'd need to place all eggs in one
> basket and trust a stranger, his integrity and security. We can do better.
>=20
> So we use multiple intermediaries. No single one of them alone
> (and thereby no one who compromised one of them) can correlate
> information that is relayed over them back to our identity.
>=20
> But while it looks like we solved the problem things actually got a lot
> more complicated. Now we trust in a "network" of strangers. The
> "network" knows our identity and so does everyone who compromises the
> network.
> Since our "messengers" aren't real people a single adversary can pretend
> to be many messengers. He doesn't even have to control the
> majority of all peers to pose a serious threat to the anonymity of everyo=
ne.
>=20
> There are further problems, some so called "decentralised" networks in
> fact rely on centralised bootstrapping. We not only have to trust the
> "network", in addition we have to trust a single central authority. If
> that part gets compromised our anonymity is broken.
>=20
> Finally there are attacks from "the outside". An attacker doesn't have
> to compromise anyone if he can track the messages simply by watching the
> communication between "you" and the messengers. This generally does
> apply to all mentioned approaches and only depends on their specific
> implementations (encryption, padding, multiplexing, latency...)
>=20
> But the fundamental flaw shared by all of them is that they are based on
> the assumption that we trust someone whom we actually don't trust.
>=20
> By definition anonymity in this context needs a third party. Further
> this implies that we need to trust this third party with our identity.
> We need trust because we can't verify anonymity.
> (Compare that to privacy where all that's needed is Alice and Bob and
> cryptography can offer mathematical verifiability - to some extents)
>=20
> The only way to solve the dilemma is to make sure that we only have to
> trust people we already trust. We must trust them that they are indeed
> different real persons, that they aren't colluding and that it's
> difficult to compromise all of them without being tipped off.
>=20
> In other words, the only sensible approach to strong anonymity is a
> fully decentralised darknet. Anything else is flawed by design and can't
> ever be fixed, no matter what feature you bolt on. Concrete
> implementations of darknets today have a range of weaknesses but those
> aren't inherent and can be fixed.
>=20
> There is another, quite different approach to anonymity/pseudonymity.
> Instead of using middlemen you could yourself pretend to be someone else
> by disguising your identifying features.
> You wouldn't have to trust anybody. However, for obvious reasons, this
> isn't a concept worth further pursuing.
> But it's an important argument whenever the idea of strong anonymity is
> attacked with arguments like: "But you are helping the <insert
> bogeyman>". They already have the means for conceptually even stronger
> anonymity as they probably don't care about the illegality and
> collateral damage of their methods.
>=20
> Would you agree with this analysis? I'd be very interested in your
> comments and criticism. Are there any other fundamental concepts to
> "solve" anonymity?

Seems a reasonable analysis. Explains some of the difficulties with mixnets=
: Most notably peer selection, if the bad guys can strongly influence peer =
selection they can bust you even though in theory to break the onion you ne=
ed to compromise all the nodes involved.

There are some other factors here though:

=46reenet isn't a mixnet. By the standard mixnet-favouring cyberpunk measur=
ements, Freenet isn't all that strongly anonymous (but mixnets do have prob=
lems of their own, as you alluded to). Tracing users on Freenet is relative=
ly easy if you can connect to everyone (which is obviously not possible on =
darknet), and more or less feasible if you can move around on the network a=
nd recognise large amounts of content (the first condition is expensive on =
darknet but cheap on opennet, the second condition is true if somebody is v=
ery chatty, inserts big files as CHKs or reinserts files).

=46reenet values unblockability and censorship resistance as well as anonym=
ity. Mixnets don't store data; Freenet stores data. This actually prevents =
some attacks e.g. most uptime intersection attacks.

I have posted some ideas on devl for using mixnets for the top SSK blocks t=
o mitigate the second attack I mentioned (based on Ian's work). This involv=
es routing through strangers, but should be somewhat safer as long as routi=
ng/topology/swapping isn't too hopelessly broken. Most of the traffic analy=
sis related issues, and a lot of classic mixnet attacks, can be avoided if =
you don't care too much about latency. Given that publishers are generally =
in far more danger than readers, and given that latency usually doesn't mat=
ter so much on publishing, this allows some very interesting options.

--nextPart1902811.UMAPPn223s
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABEIAAYFAk1ySx4ACgkQYUNbc3WUHYiK+gCgiiytFOPk4BRi7THwOjHs25FH
6TcAoK2WOjP7IN3XSHuL15fy9uUJli+/
=Sbrw
-----END PGP SIGNATURE-----

--nextPart1902811.UMAPPn223s--

--===============0992327810==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
chat mailing list
[email protected]
Archived: http://news.gmane.org/gmane.network.freenet.general
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/chat
Or mailto:[email protected]?subject=unsubscribe
--===============0992327810==--