Re: [tor-talk] End-to-end correlation for fun and profit

2012-08-25 Thread With Weather Eye Open
 Original Message 
 
> From: Maxim Kammerer 

> 1. Stop spreading FUD and false claims, 

You are projecting.

> (c) proposing to invoke an attorney on some kid who tries to work on
> an open-source project he likes.

There is nothing wrong with using the legal process to protect your IP 
especially when someone who is misusing it is not willing to comply with simple 
requests and demands.
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


[tor-talk] Tails question: Desktop in laptop mode during shutdown, mysterious sense data?

2012-08-25 Thread gooseeggz
Why is my desktop being shown as in laptop mode when I shutdown? There's also 
some myserious
"SENSE" or "sense" data shown, much like would be shown within a binary. The 
shutdown screen
quits after wiping so I don't have a chance to catch the information to write 
it down unless
I take a photograph of the screen with a camera. What is this info and why is 
my desktop
being put into laptop mode? The SENSE data is always the same, a few lines 
which appear like
hex data from a binary.

I'm posting here because this was not solved/addressed on the Tails forums.
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


[tor-talk] Tails question: Cannot rename old configuration file (torrc.orig.1)

2012-08-25 Thread gooseeggz
When the network is up and Vidalia/tor/browser all opens, I peek inside the tor 
log (/var/log/tor) and this error is included:

[notice] Renaming old configuration file to "/etc/tor/torrc.orig.1" [warn] 
Couldn't rename configuration file "/etc/tor/torrc" to "/etc/tor/torrc.orig.1": 
Permission denied

torrc is owned by root:root

I've tried a number of changes in ownership but nothing will allow the changes 
to be written for the torrc file, has it always been broken like this?

How to fix?

Posting here because this was not solved/addressed on the Tails forums.
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


[tor-talk] GWeather - giving away location data? How to disable?

2012-08-25 Thread gooseeggz
When I set the location in the clock/location settings, I notice the following 
errors in .xsession-errors:

(gnome-panel:): GWeather-WARNING **: Failed to get METAR data: 504 Connect 
to weather.noaa.gov:80 failed: Connection refused.

When I try to remove GWeather from the system, it throws up several important 
dependencies so I cancel the removal.

When I rename the libgweather.so* files to something else it breaks the 
libclock-applet.

I don't want my system trying to fetch weather information, especially not from 
a ** GOVernment site! **

Because of this stupid GWeather bug, this remains open until I shutdown:

127.0.0.1:8118 CLOSE_WAIT /gnome-panel

The failures above eventually vanish when I check my location at a later date, 
when clicking the clock applet, it shows the weather for my area which I 
specified after boot!

If I unselect showing the
weather it grabs it anyway! And how often does it update the weather? Only when 
I click on it
or at various timed or random intervals? I'm not using the regular weather 
applet which must
be manually added to the panel, this is under the clock applet/location area.

How may I safely disable GWeather without killing the clock applet? I need to 
enter my location
when running from a LiveCD (such as Tails, I asked on their message board but 
no one responded)
so the time is up to date, enough for Tor to work. Otherwise if I don't enter 
the correct location
Tor views my system time as invalid and halts with errors.

I believe this is a heavy erosion privacy.
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


Re: [tor-talk] End-to-end correlation for fun and profit

2012-08-25 Thread Mike Perry
Thus spake Maxim Kammerer (m...@dee.su):

> On Sat, Aug 25, 2012 at 1:12 AM, Mike Perry  wrote:
> > The Raccoon has made a believer out of me, but there are some limits to
> > both of his/her proofs.. The full proofs can still be found here:
> > http://web.archive.org/web/20100416150300/http://archives.seul.org/or/dev/Sep-2008/msg00016.html
> 
> Wrt. the first proof, it seems to me that the assumed correlation
> accuracy rate of 99.9% is incredibly low, and I think that the Raccoon
> recognized that by referring to sampling and retention at the end of
> his post. With the targeted attack that's similar to “Example 3” in
> Raccoon's post that I described in my previous comment here, where one
> analyzes all exit traffic without missing packets, I would expect the
> correlation accuracy (and as a result, match confidence) to
> exponentially approach 100% very quickly with the number of relevant
> packets seen, and extremely quickly if the traffic is interactive
> (i.e., browsing).
> 
> Actually, c/n of 30% in “Example 3” is close to the 25% that's
> discussed in the OP here, so let's redo the example with c/n=25% and
> different correlation accuracies (leaving the other numbers intact):
> 
> (using “bc -l”)
> ca  = 0.999
> pm  = (1/5000) * (0.25)^2
> ca*pm / (pm*ca + (1-pm)*(1-ca))
> 
> ca  = 0.999
> .01233363786760166917
> ca = 0.
> .0246894375430565
> ca = 0.9
> .5617284636495961
> ca = 0.99
> .92592671467910125759
> ca = 0.999
> .99206358969515668554
> ca = 0.
> .99920064946444143613
> ca = 0.9
> .2000739924807495
> 
> So reducing correlation accuracy error to 10^-9 will give you 99.99%
> confidence in end-to-end correlation match. I suspect that a few
> seconds of interactive traffic will give you a correlation accuracy
> that's much better than a 10^-9 error.

Well, the argument over correlation accuracy comes down to observation
resolution, feature extraction ability, and academic lab conditions
versus reality. For an example, let's assume that the adversary cannot
see inside of Guard TLS connections. With this assumption: if at any
point there's concurrent Guard TLS activity from a single client (either
other circuit activity, directory fetch activity, or circuit
pre-building activity), then some or all of your fine-grained timing and
size information features go out the window.

To see the effects of this currently, consider: Is it *really* the case
that only one connection in *a billion* experiences incidental
concurrent activity that interferes with or obliterates high-resolution
feature extraction? I think the actual rate of random (or deliberate)
concurrent activity is much higher than that, especially for heavily
used tor clients, and even more so if they are serving as bridges or
relays. 

But, against high-resolution adversaries, the really interesting
question is: How little real cover traffic is actually needed to obscure
timing and size information to the point where the remaining features
are insufficient for high rates of correlation success? And over how
many observations can such activity be expected to survive for a given
base rate of similar activity?

I suspect that for relatively short-lived bursts of traffic like web
site views and random webapp AJAX activity, we can actually do pretty
well with very little effort and overhead. Especially against the
one-ended version of the correlation attack: the website fingerprinting
attack, but probably against both.

But for long-lived or otherwise atypical connections, you're absolutely
right. There's just a whole lot of information encoded there.. Almost
any level of observation will likely be able to correlate such flows
eventually, and it's also hard to imagine generalized padding techniques
that could blend these flows with web traffic.

Unfortunately, because academia has mostly concluded that this work is
uninteresting and that all forms of this problem are generally
"impossible", we have no solid answers to these types of questions wrt
what can be done in practice. Perhaps it is merely because defense
work is less sexy than attack work when it comes to getting
publications. I don't know for sure. I haven't yet figured out exactly
why CS academia is broken. There's a whole lot of symptoms, though...

But anyway, failing real research, there's always the botnets, the drug
war, and the aliens to guide us... Can I get three cheers for Big Data?
After all, I'm sure we can trust Them to tell us how the science shakes
out in the end, amirite? ;).


-- 
Mike Perry


signature.asc
Description: Digital signature
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk