NSA can decrypt Tor Traffic?

You can't choose the path (the Tor client does this) but you can choose the exit node and set preferences for which nodes you wish to use or avoid.

 

. Thanks for the info. I have heard that donating bandwidth to tor increases anonymity. Is this true?

 

Powerful governments (US/UK/China) have this ability, as do super telecoms such as UUNet, QWEST and AT&T. This can be done with pretty much any low-latency anonymity network. This is why I say there is a tipping point, those who are less than a superpower don't have the capability, those who are don't need to bust your encryption to bust your identity and traffic.

 

Re: Any good reasons?

We use MAC, but there is more than one MAC implementation. OpenVPN supports two different HMAC functions. The packet HMAC and the control channel HMAC. The former is enabled in our setup. The latter isnt.

What these do:
- Packet HMAC: Generated during TLS handshake a shared key for HMAC signature is created. This is applied to the encrypted packet and the HMAC appended. This is good enough to throw away modified packets. We use that, have always used it. The algorithm is SHA1.

- Control channel HMAC: This one is based on a preshared secret key. It is basically used as an additional authentication method before the TLS handshake takes part. While this is a cool thing in closed group trusted user setups it does not apply in our case. Since the preshared key has to be the same for everyone it does not bring any additional security. It decreases security by increase of complexity without additional protection (because the key is not secret). This is what the tls-auth option controls. It is disabled in our setup.

 

That makes sense, then.

Alright. That makes sense, then. I had a feeling this was what you were probably doing. Cheers!

 

Re: That makes sense, then.

\

How ironic to use SHA1, the SHA hashes where designed by the NSA.

Look here, the first sentence talks about the NSA.
http://en.wikipedia.org/wiki/SHA_hash_functions

(I don't mean to say that therefore they are unsafe to implement, its just ironic)

About, can the NSA decrypt TOR traffic. They don't have to be doing that because, as pointed out earlier. There is first traffic analysis, next to this technique they can collect and store all your TOR-traffic no matter how old, and afterwards, if they would like to decrypt it, which is very unlikely because they don't need to, they could steal your torrc-file through a backdoor in software, or a Trojan that searches specifically for this file on the target computer. This method also saves them from using allot of supercomputing power. You don't have to be the NSA to be able to do this at all, more low-tech groups can also do this. Its the same method used against your private PGP key, or any other crypto key. besides this all, The NSA is 10.000 times more advanced than a thing like TOR, And 5 times more than we can imagine.

TOR is a nice solution if you like to keep your employer, ISP, or large telecom corporations from knowing what you are up to on the Internet. Not to hide things from the NSA, the Internet was not designed to be. A thing like XeroBank comes closer to maybe accomplishing that.

This is a nice study on the effects of low-cost traffic analysis against TOR, done by Steven J. Murdoch and George Danezis from University of Cambridge. (if you haven't seen it already) So not with a NSA budget.....

 

The NSA and us.

I touched on this in a previous post of mine, from another thread. As I pointed out there, we're relying on an NSA-designed hash function, SHA-256, as our interim standard, for which we don't even have the design criteria. The truth is that, despite hash functions being the workhorses of cryptography, we don't know as much about there design as we'd like to. We're getting there, and the NIST's public competition for a new hash function standard will certainly help us.

Ideally, the NSA would lend us a hand (i.e., submit a hash function of their own), but the chances of this happening are slim to none, it seems. They didn't submit a block cipher to the AES competition, and the reasoning given was along the lines of the NIST wanting them to be an impartial judge; this reason may be recycled for the hash function competition as well. They could at least publish the design criteria for SHA-256, so we'd know just how much security we're gaining beyond SHA-1. Some might be wary of the NSA, but if there was ever an instance where we could learn from them, this is probably it.

(As far as I know, the submission deadline should be sometime during the 4th quarter of 2008, with the winning hash function(s) being chosen by the 2nd quarter of 2012. The standard should signed by the Secretary of Commerce during the 4th quarter of 2012. This could change, so don't quote me!)