Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] New Anonymity Network for Short Messages

Michael Rogers michael at briarproject.org
Wed Jun 12 10:09:14 PDT 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/06/13 16:52, Sean Cassidy wrote:
>> * A passive observer can pretty quickly tell which prefixes a
>> client subscribes to by seeing which messages routers send her -
>> her outgoing messages can be ignored. So can't a global passive
>> observer identify a group of clients who all subscribe to the
>> same prefix?
> 
> Prefixes are intended to be small in order to get a large amount
> of messages. Clients can (and should) connect to multiple endpoints
> and get messages for multiple prefixes, as well as respond on
> those prefixes. Perhaps there could be a control channel on the
> network to set up random pairs (or groups) of people in order to
> correspond their fake prefixes.

It would be good to see some back-of-an-envelope calculations of the
anonymity set size (or any other anonymity metric) as a function of
the number of clients and the number of fake prefixes each client
subscribes to. My intuition is that there will be lots of pairs of
clients who subscribe to the same fake prefix, fewer trios, even fewer
quartets, etc. So large groups who subscribe to the same prefix will
still stand out.

The control channel suggestion is interesting, but if the adversary
can monitor the control channel, won't real subscriptions stand out as
they won't have been arranged using the control channel?

Choosing an appropriate lifetime for fake subscriptions seems like a
difficult job. Presumably clients will want to join and leave
conversations, so their real subscriptions will change. The dynamics
of fake subscriptions will have to resemble the dynamics of real
subscriptions to avoid revealing the real subscriptions to a long-term
passive observer.

> The router does not trust the hash, but instead recomputes it and 
> checks it against the given checksum. It was intended to
> discourage attacks that just flipped a bit and flooded the network,
> but this is sort of a weak protection.

If the attacker can flip bits, surely she can also replace the hash in
the packet with a new hash calculated after flipping the bits?

> I also had envisioned that clients could monitor their messages
> from multiple endpoints (subscribe to themselves) and check that
> the checksum is still the same one that was sent. If they never
> receive that checksum, either the network is not connected
> properly, or there is some destructive tampering going on.

That sounds like a useful check, but it doesn't require the hash to be
included in the packet - clients can store the hashes of the messages
they send, calculate the hashes of the messages they receive, and
check that they receive all the messages they send.

So it still seems to me that the checksum field is redundant.

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

iQEcBAEBAgAGBQJRuKs6AAoJEBEET9GfxSfMgJkH/jn0cSbr+iQmeOlTR3C35WFZ
whnq/fsr0Vls/DNk8tHmK3sC+WNQa4bFPwUoEzAluFa1N/ENxIkcArZyAANyAB8+
Ar/xFBWM7yD1MbIJkY+ljyrFE5DIe3u/P4olvvzDvhiBQr4SPPDCLlKV+7YGC6lS
lxM/x8p2iYpAx6qh1TwlsDXfF20/45RgK50fFoB9vegylQCJ5pSlProm9Es9/YEX
c07+ab9LdV59M86yaPBQflniz7UH68dctoCGoKfihbtei4ic+AIv6sFAViti2tzj
b89fO1aNE5lMHutXkYRAmtaxTkuXIU+4Rz3+v3rZy4cYL30yVXIlipSG9TJvZ7g=
=IMVC
-----END PGP SIGNATURE-----



More information about the liberationtech mailing list