On Wed, Jun 12, 2013 at 6:34 AM, Michael Rogers
<mich...@briarproject.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/06/13 17:52, Sean Cassidy wrote:
>> I have created a simple anonymity network that broadcasts all
>> messages to participants so that you cannot associate chatters.
>
> Hi Sean,
>
> A few quick questions:
>
> * Do routers subscribe to prefixes, or is it only clients that do so?
> If routers subscribe to prefixes, how do you ensure that all routers
> subscribed to a given prefix form a connected subgraph?
ZeroMQ (the library I used to connect routers) allows for filtering
based on messages, but the software as implemented does not support
this. There is actually a bigger issue in ensuring a fully connected
network: the links are not automatically bidirectional. The network
operators must ensure that the graph is connected properly. I did this
to make the routing algorithm (if you can even call it that) simple
and straightforward.
> * 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.
>> struct dinet_packet { uint8_t id[16]; // prefix + random in the
>> default client uint8_t data[1024]; uint8_t checksum[32]; // SHA-256
>> checksum of the previous two fields, to avoid flooding the network
>> with duplicate packets };
>
> * Why is the checksum included in the packet? Each router can
> calculate the hash of the previous two fields itself, and discard the
> packet if the hash matches a previously seen hash. If the router
> trusts the hash included in the packet, it's possible to poison a
> router's duplicate detection cache by sending it a packet that has the
> same checksum field as another packet but different data.
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.
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.
Sean
>
> Cheers,
> Michael
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJRuHkBAAoJEBEET9GfxSfMygkH/i7iLj0IhYRqP0Ux6DPjyyK8
> zljvmL1cft8uhd3CTOz3sYGzJIiduQuDHG1UEEsNKNMJxETSgQXylQRKPodqPa5Z
> a7XLjtyp2Y6Tx/5PC3CU7vtaXvnG+ZLrIsfXsjatQx6sEVoN7dMGPTP3jyaSJl4f
> 3fp2ZhT0CAFpzXrGnGfOdttoNaKo9KSFTcYIsp/jVdC1YCmaexHpF5j2QjQ8cX83
> WEhSZAuhpAUzAwutFpC9H8rpxbcZstucq4TsbjlVsgV0v/UbdYB5Th0UGn6fTISY
> z78PK+HU+Co/HXw7VQpd3CZq3Ng03/09na0ZvEbEZqpIwwJrzyZOffNnObd648k=
> =SLCZ
> -----END PGP SIGNATURE-----
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at compa...@stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
--
Too many emails? Unsubscribe, change to digest, or change password by emailing
moderator at compa...@stanford.edu or changing your settings at
https://mailman.stanford.edu/mailman/listinfo/liberationtech
