-----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----- -- 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
