Whenever I read something, with an open mind, but say, in a sandboxed
environment (don't run your memes on root), I get impressed by arguments
which convince me of things which are not true.
Take for instance the following article:
https://blog.torproject.org/blog/tor-security-advisory-relay-early
Also: just because it's HTTP/S running over a different network stack,
doesn't make it a new scheme.
Just because your dinner arrives on a different plate doesn't mean the
recipe has changed. :-)
---
https://bugzilla.mozilla.org/show_bug.cgi?id=1228457
Tor is a strange sort of sacred cow
highl
https://tools.ietf.org/html/rfc3986#section-3
By placing the scheme within the authority as a tld while using the same
authority as the HTTP specification, this probably breaks RFC 3986 and
maybe others.
I might be a bit late in saying this.
___
tor-dev
I've never seen anything download faster than ten megabits per second on
Tor. Presumably the inverse is true if you have upload.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
> (as opposed to the people that seem to think that Exits
> should actively combat abuse by having the capability for censorship).
>
>
Well, a large number of exit nodes already have the capability for a
man-in-the-middle attack. This capability could very well be a default
option.
b) In your m
I could see why cloudflare is annoyed with you, you are annoying
activists from their perspective, although you folks aren't chaining
yourselves to coal power plants . But I also use Tor from time to
time, so I'll offer some advice.
On the Tor side, a way to minimize abuse is for exit nodes not to
I just want to note you only need an algorithm that protects against
2^80 quantum operations for short-term keys.
Regardless, I doubt anyone is going to be spending a billion dollars
to crack data sent over a single Tor connection.
___
tor-dev mailing li
Wasn't there a transition period in migrating from RSA to ECC?
Maybe I'm just confused. Or you are confused. But I think it is best plan
for a five or ten year transition period.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproj
>
> We had a GSOC project to produce "consensus diffs", so that clients could
> download the differences between each consensus each hour, rather than
> downloading a full consensus (~1.5MB).
>
> It showed some great results, but still needs a little work before we merge
> it.https://trac.torpro
And yet the NSA is moving to prime numbers.
A large public key isn't a very good reason to not adopt quantum-safe
crypto, it just means that it requires having the Tor project to be able to
scale to a larger degree. I suggest hash tables, a percentage of which are
pseudorandomly downloaded. Otherw
The first step should be replacing the long-term keys with quantum-safe
crypto.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Mon, Sep 29, 2014 at 4:36 PM, isis wrote:
> Ryan Carboni transcribed 1.1K bytes:
> > There's one issue if you remove all the small relays, only relays run by
> > the NSA will be around. Not many people have access to multi-megabit
> upload
> > speeds. And thos
There's one issue if you remove all the small relays, only relays run by
the NSA will be around. Not many people have access to multi-megabit upload
speeds. And those that do might also be using bittorrent.
___
tor-dev mailing list
tor-dev@lists.torprojec
>
> But, because this is fraction rises with both D and U, these research
> papers rightly point out that you can't keep adding relays *and* users
> and expect Tor to scale.
Broadcast a fraction of all available directories? Use md5 as a random
number generator, hash the ECC/RSA keys using md5. A
14 matches
Mail list logo
