I would say advantages of ECC are:
Performance—see Curve25519 performance on linked page
More analysis—this is debatable, but I would say ECC is better understood in the crypto community than lattices.
Spotty history of NTRU, which had to be revised several times, IIRC, based on cryptanalytic attacks.
I think there might also be patent issues around NTRU, ...
Tor does not make much use of more than one core, two cores (or one hyperthreaded core) per process is best
a maximum of two Tor processes may register from a single IP, so a CPU with 4 cores is ideal
64-bit is best for cryptography
2 GiB of system memory is a bare minimum
Whilst I can't back it up with much technical details, this is from what I ...
A very quick, back-of-the-envelope answer...
Let's take a YouTube or Netflix video to stream at 4.5 Mb/s, which is probably higher than average. I'll ignore baseline, non-video traffic for now.
If 100,000 people simultaneously started using Tor for video streaming, that'd be an extra 100,000 * 4.5 Mb/s (= 450,000 Mb/s). That's 450 Gb/s.
The advertised ...
(This is in regards to meee's response, but I don't have enough reputation points to add a comment)
They do include BSD and a bunch of other licenses in their FOSS license exception:
So Tor should be able to use libntru which is BSD-licensed, but it might still not be a ...
I did further research on this.
NTRU appears to have an exception only for GPL code (there is a version by the company creating NTRU), but since Tor is BSD it won't fit well. (not true, see Tim Buktu's comment)
Also researching on this question it seems that at leas Jacob Appelbaum (Tor developer) did some research on this too: https://twitter.com/ioerror/...
So far it's just something that might be useful for developers to collect. It's probably nothing that an individual user or relay operator would have to care about at this time.
It's also not even clear yet what the answer to your question really is.
As Roger explained in What is the "TLS write overhead" percentage reported in Tor log entries?, ...
Introduction points carry very little load in the hidden service protocol. They're asked once by the hidden service to accept introduction requests, and whenever one comes in, they forward it to the hidden service. That happens each time a client attempts to connect to a hidden service, and each introduction point only has to handle 1/3 of those ...
There's now a specific proposal for NTRU:
There's also an algorithm called "New Hope" that sounds to be a promising alternative:
... and apparently a new version on it's way called "Newest Hope".
This from the winter ...
NTRU for Tor is still being plugged:
NTRU does sound to be faster than some other quantum-safe algs. NTRU protects against Shor's algorithm but the standard parameter sizes for NTRU are not safe against Grover's algorithm on a quantum machine. For 128-bit parameters there's a ...
Everything goes over a single connection and using fewer connections speeds up things
This is possible, especially over a cellular network. Of your 5 theories, this is the best one.
The exit node might have a DNS cache
This is not it. A normal DNS lookup from your ISP or whatever DNS you use is at least as fast as through Tor. (There might be ...
Every client that doesn't get its consensus from some other source (clients that use bridges get theirs from the bridge they connect to) will have to connect to the Directory Authorities once at first startup, and again if they're offline for a day or longer. Tor metrics should take this into account when calculating user numbers.
For 10 minutes after a circuit is first used, new streams can be attached to it.
See the MaxCircuitDirtiness directive. So in your scenario, that 2nd connection could be setup on the same circuit 'immediately' as long as it is not too old.
I assume (but don't know for a fact) that it makes no difference whether the circuit is to an exit node or a hidden ...
I have no experience with this and I can't advice on which system to use, but you should figure out why those systems won't load any linked files. Have you looked at the links? Are they correct? Are they absolute or relative URLs? Do you get 404s or other errors in your web server log?
There is probably some way to config where your document root is and ...
When running the browser bundle it only sends the data that goes in\out of the firefox portable browser that's included with the bundle through tor.
You say you play BF4 and that ping is not affected - it should not affect BF4 at all - since that traffic is not routed through tor.
If you want to relay all traffic then you need transparent proxying or a '...
(Link has been removed, I've been unable to find it in the archive, maybe someone else will.)
on if the OpenSSL it was built against supports it.
As you're using OpenSSL 1.0.1 it should be in use, see torservers documentation.
Actually directly confirming that OpenSSL is using ...
This is not what Tor is about.
Going only through 1 IP is not secure at all. This IP could capture
all of your in-coming and out-coming traffic easily.
As with Tor, you traffic goes through 3 different servers. It's greatly saves your privacy.
But if you don't care about your privacy, you could use any public proxy.
I'm not going to tell you how to find ...
I had the same problem with Tor not opening while Webroot was running, after May 1, 2016, when it did open earlier. I checked the Event Viewer and saw the faulting application path was to firefox.exe in the Tor browser folder. So, I went to Identity Protection in Webroot and looked in Application Protection to find that firefox.exe entry. There were several ...
When you are using Tor, your traffic not only goes through the internet routers but among them passes at least 3 other routers (onion routers) these ones have to decrypt part of the information and forward it, which would cause additional time too, so the answer is yes.
Tor exit nodes are used by many users at the time and usually their bandwidth is slow.
One of the important features of elliptic curve Diffie-Hellman key exchanges using a curve like Curve25519 (which was created by Daniel Bernstein and not those people at NSA) is that it offers Perfect Forward Secrecy.
However, NTRU doesn't provide a Diffie-Hellman-like key exchange with Perfect Forward Secrecy. NTRU is a public key encryption scheme like ...