On 1/14/16, Virgil Griffith wrote:
> In our quantifications of relay diversity, knowing the IP addresses that
> traffic exits from is important. Ways to have this information correctly
> reported would be very helpful.
i want to be very clear:
asking relays to report their public exit IPs in cen
On 1/13/16, grarpamp wrote:
> On Tue, Jan 12, 2016 at 9:58 AM, coderman wrote:
>> ... only question is who would have a
>> compelling use for separating outbound OR connections and outbound
>> Exit traffic, as per #17975?
>
> Bandwidth peering contracts preferential
On 1/12/16, Tim Wilson-Brown - teor wrote:
> ...
> The current tor implementation simply calls connect() if OutBoundBindAddress
> is not set for the destination address family.
> This means that the connection will be made from a source address based on
> the routing table entry for the destinatio
On 2/16/07, Christopher Layne wrote:
> Thought you guys might find this interesting. I did a couple of callgrind
> runs ...
yes, really back to 2007 to find a callgrind on a relay.
does anyone have a more recent profile of a busy relay, by chance?
if none exist, what do i need to bribe you with
On 7/24/15, Yawning Angel wrote:
> ...
> I have less objections towards people using tor-fw-helper for bridges
> than for something like flashproxy or full fledged relays.
> ...
> IMO similar to relays with insufficient bandwidth, relays that can't
> connect to any other relay on demand as require
On 5/2/15, coderman wrote:
> ...
> we're soliciting feedback as part of a go / no-go decision on
> continuing this effort.
>
> in particular, the design is intended to meet the scrutiny of Nick M.,
> Roger, and Mike P. as the focus on support for Tor Browser and Tor on
On 5/4/15, Mike Perry wrote:
> ...
> In my opinion, the most interesting use case for these devices is where
> Tor Launcher implements a peering mechanism whereby the user can click a
> button at some point in the initial connection wizard that says "My
> Router Knows My Tor Configuration."
hi Mi
On 5/4/15, Mike Perry wrote:
> ...
> In my opinion, the most interesting use case for these devices is where
> Tor Launcher implements a peering mechanism whereby the user can click a
> button at some point in the initial connection wizard that says "My
> Router Knows My Tor Configuration."
>
> Wh
On 5/4/15, coderman wrote:
> ...
> this deserves a longer answer, but you're right. if the attacker is
> using Tor itself a Tor enforcing gateway can't protect against those
> attacks.
i have updated the document to make this more clear.
it is hard to express the nuance
On 5/4/15, Leif Ryge wrote:
> ...
> So, unlike a transparent tor router, this system is not intended to prevent
> malicious software on client computers from being able to learn the client
> computer's location, right?
hello Leif!
this deserves a longer answer, but you're right. if the attacker
On 5/3/15, teor wrote:
> ...
> Some users will want as little logging as possible, as it can lead to
> privacy leaks if the device is compromised - may I suggest you turn it off
> by default?
you are correct; the default should be no logging. i have updated the
document, and noted that any loggin
On 5/3/15, warms0x wrote:
> ...
> I am bored so I figured I would read this big document, here are some
> comments from somebody who took the time to care:
thanks! :)
> 1.3 > Warning conditions:
>
> Is the "Client privacy leak detected" meaning the software would warn
> in the case of a LAN cl
On 5/3/15, intrigeri wrote:
> ...
> Just to clarify, the threat model explicitly doesn't include "Attacker
> is able to reconfigure Tor on a client system to use an arbitrary set
> of bridges", right?
correct.
neither bridges nor pluggable transports are supported. i have added a
FAQ entry for t
a friend and i are working on a Tor router design that doesn't
compromise anonymity for convenience. [0][1][2][3][4]
we're soliciting feedback as part of a go / no-go decision on
continuing this effort.
in particular, the design is intended to meet the scrutiny of Nick M.,
Roger, and Mike P. as
On Wed, Dec 18, 2013 at 7:05 PM, Nick Mathewson wrote:
> ... Is there any actual harm in the redundant invocation of
> ENGINE_register_all_complete(), or is this about cleanliness/saving
> cycles/something else?
>
> Assuming it's not actually harmful, I'd prefer to leave the call in,
> with a comm
,
On Wed, Dec 18, 2013 at 9:57 AM, coderman wrote:
> hello all, Nick,
>
> per the other thread in tor-talk about RDRAND, this is the minor fix
> for OpenSSL 1.0.1+ mentioned.
>
> i don't know that this is useful, and i am still giving the engine
> code a thorough review
hello all, Nick,
per the other thread in tor-talk about RDRAND, this is the minor fix
for OpenSSL 1.0.1+ mentioned.
i don't know that this is useful, and i am still giving the engine
code a thorough review per Nick's other feedback: "Above all, do not
assume
that you understand how OpenSSL works
On Sat, Nov 16, 2013 at 3:58 PM, Erinn Clark wrote:
> ...
> I tried to get the licensing agreements earlier this year and they are, as far
> as I can tell, not available until you actually sign up. If someone reading
> this has put something in the app store (which may or may not be different
> f
On Tue, Oct 8, 2013 at 8:40 PM, Watson Ladd wrote:
> ...
> The _easy_ fix is to make go.crypto constant time,
"You Keep Using That Word, I Do Not Think It Means What You Think It Means"
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://list
On Wed, Sep 5, 2012 at 11:52 AM, David Goulet wrote:
> ... the problem of "bufferbloat" which is encountered in network
> bottlenecks.
>
> https://en.wikipedia.org/wiki/Bufferbloat
> http://www.bufferbloat.net/
yup. particularly bad at the edges...
> Anyhow, I looked around for some recent stud
On Tue, Nov 1, 2011 at 1:20 PM, Zooko O'Whielacronx wrote:
> ...
> Therefore, in the context of whether we can expect SHA-3 and/or
> SHA-256 circuits to come built into our chips in the future, the fact
> that SHA-256 can be implemented in a smaller circuit means it would be
> cheaper for a chip m
On Tue, Sep 27, 2011 at 4:20 PM, Rob Jansen wrote:
> ...
> For the unaware, we have been working on the design and development of
> Shadow, a simulator capable of running real binaries over a simulated
> network, and a plug-in that runs real Tor. Shadow can simulate roughly 1000
> Tor nodes in 10
On Wed, Aug 24, 2011 at 12:21 PM, Georg Koppen wrote:
> ...
> [blah blah] about the rise of slow DOS attacks and that Tor could play
> an important role in it
> ... I am wondering whether there is already some
> effort under way to detect and ban such kind of traffic. Or should there
> be such eff
On Thu, Jun 9, 2011 at 2:34 PM, Jacob Appelbaum wrote:
> ...
> We need a proposal for a circuit selection process that is BGP aware. I
> guess we'll need it around the time that we want to support IPv6 entirely...
why stop at BGP? at that point, might as well pay for a telegeography
subscription
24 matches
Mail list logo
