Re: [liberationtech] Traffic Analysis Countermeasures
Charles Allhands allhand...@gmail.com writes: Does anyone know of software designed to thwart traffic analysis? With all the recent news about metadata gathering this would seem like a useful privacy tool alongside Tor and good crypto. There was this interesting project, called sniffjoke: http://www.delirandom.net/sniffjoke/ but it doesn't appear to be developed anymore (last update 2 years ago...) micah -- 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
Re: [liberationtech] Traffic Analysis Countermeasures
The Doctor: On 07/18/2013 11:51 AM, Charles Allhands wrote: Thanks for the link! Is there a reason why mix networks aren't commonly used? I see mixminion hasn't been worked on in years. One possible factor may be that many people are less interested in anonymity of communications (i.e., sending e-mail) and more interested in anonymity of net.access these days. I doubt that there is only one factor contributing to the general lack of advancement in this field, though. Another good argument made on tor-talk (and probable a few other places) was, that the user interfaces were never user friendly. -- 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
Re: [liberationtech] Traffic Analysis Countermeasures
Mix Networks are designed to do this, with remailers being implementations of them (although quite out of date, and best studied academically and not relied on. An intro, in blog form, is here: https://crypto.is/blog/ Shared Mailboxes like the usenet group alt.anonymous.messages also are designed to defeat traffic analysis, and are in the same state of disrepair and academic study. I aim to present more about AAM this month: http://defcon.org/html/defcon-21/dc-21-speakers.html#Ritter I agree, I think defeating traffic analysis and metadata collection is crucial - but we don't have many mature tools that aim to do this. Tor is the best example. -tom -- 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
Re: [liberationtech] Traffic Analysis Countermeasures
On Thu, Jul 18, 2013 at 10:51:23AM -0500, Charles Allhands wrote: Thanks for the link! Is there a reason why mix networks aren't commonly used? I see mixminion hasn't been worked on in years. Most of the payload of mix was spam and malware. It's effectively an open relay as far as RBLs are concerned. So not very useful. -- 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
Re: [liberationtech] Traffic Analysis Countermeasures
Charles Allhands: Thanks for the link! Is there a reason why mix networks aren't commonly used? Thanks for asking this interesting question. See this. Not written by me. Source [1] Roger Dingledine Fri, 27 Apr 2012 00:10:48 -0700 On Thu, Apr 26, 2012 at 04:15:04AM +0100, StealthMonger wrote: If the channel has low latency, no hacking can conceal the packet timing and volume correlation at the endpoints. It is high random latency and thorough mixing that gain mixmaster its anonymity. Dingledine and company would agree. Your thorough mixing phrase is critical here. Once upon a time, when we were working on both Mixminion and Tor, we were thinking of it as a tradeoff: Mixminion offers some protection against end-to-end correlation attacks [1], but the price is high and variable latency; whereas Tor offers basically no protection against somebody who can measure [2] flows at both sides of the circuit, but it's a lot more fun to use. (Another price of the mix design is that you only get to send a fixed-size relatively small message rather than have a bidirectional flow.) So oversimplifying a bit, we thought we had a choice between high security, high latency and low security, low latency. But the trouble is that while Mixminion's design can provide more safety in theory, it needs the users before it can provide this safety in practice. Without enough users sending messages to mix with, high and variable latency by itself doesn't cut it. So oversimplifying a bit more, the choice may be better viewed as low security, high latency vs low security, low latency. And that's a much easier choice to make. See [3] for more discussion. I haven't given up hope on end-to-end correlation resistance for low-latency flow-based designs like Tor (but papers like [4] don't make me optimistic for a quick fix). It's hard to see how we could end up with a large enough and diverse enough population of Mixminion users to let it fulfill its potential. Stay tuned to PETS [5] and related conferences, but be patient. --Roger [1] http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg00022.html -- 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
