Mike Perry writes:
> George Kadianakis:
>> Hello there,
>>
>> recently we've been busy specifying various important improvements to entry
>> guard security. For instance see proposals 250, 241 and ticket #16861.
>>
>> Unfortunately, the current guard codebase is dusty and full of problems (see
George Kadianakis:
> Hello there,
>
> recently we've been busy specifying various important improvements to entry
> guard security. For instance see proposals 250, 241 and ticket #16861.
>
> Unfortunately, the current guard codebase is dusty and full of problems (see
> #12466, #12450). We believe
Hi Leeroy,
On Fri, Aug 21, 2015 at 08:09:13AM -0400, l.m wrote:
> Hi,
>
> I'm curious what analysis has been done against a gateway adversary.
> In particular dealing with the effectiveness of entry guards against
> such an adversary. There's a part of me that thinks it doesn't work at
> all for
Hi,
I'm curious what analysis has been done against a gateway adversary.
In particular dealing with the effectiveness of entry guards against
such an adversary. There's a part of me that thinks it doesn't work at
all for this case. Only because I've been studying such an adversary
at the AS-level
s7r writes:
> Hi,
>
Hello, thanks for the feedback!
I pushed some small updates to my branch based on your comments.
You can check them out here:
https://gitweb.torproject.org/user/asn/tor.git/tree/src/or/guardlist.c?h=bug12595
> On 8/20/2015 2:28 PM, George Kadianakis wrote:
>> Hello ther
isis writes:
> George Kadianakis transcribed 5.2K bytes:
>>
>> - This new design focuses on protecting against path bias attacks, by
>> slightly
>> damaging our reachability.
>>
>> Specifically, the old design is better at recovering in filtered networks,
>> because it will keep on adding
George Kadianakis transcribed 5.2K bytes:
>
> - This new design focuses on protecting against path bias attacks, by slightly
> damaging our reachability.
>
> Specifically, the old design is better at recovering in filtered networks,
> because it will keep on adding new nodes till one succeed
> On 21 Aug 2015, at 00:07, s7r wrote:
>
> Can you suggest a retry amount and time interval? I think 10 times
> once every 20 minutes for the Guards we selected but never connected
> to and double or even triple that for the Guards we remember we were
> once able to connect to is reasonable.
Th
> Thanks for the input!
Hey, no problem. Thank you for working on this too.
> Can you suggest a retry amount and time interval?
If the adversary is at the gateway and can do filtering, they pretty
much want some rotation. Whatever that reason may be (choose a guard
you've already chosen, or choo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Thanks for the input!
On 8/20/2015 4:59 PM, l.m wrote:
>
>> "b) ..."
>
> Retrying guards is the crux of the problem. If you blindly retry
> guards, even to prevent rotation, you eventually come to a hard
> place where this will backfire badly
> "a) The network is not hostile and allows access just fine, but..."
This came up before didn't it. Nick mentioned that the question
`network down` isn't the easiest question to answer portably.
Supposing such a network could have it's properties (like route)
enumerated this might provide anothe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Also, we should choose a reasonable amount of retry attempts at
reasonable time periods for the Guards in primary_guard_set, for the
following reasons:
a) The network is not hostile and allows access just fine, but:
- - the user walked out the signa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
On 8/20/2015 2:28 PM, George Kadianakis wrote:
> Hello there,
>
> recently we've been busy specifying various important improvements
> to entry guard security. For instance see proposals 250, 241 and
> ticket #16861.
>
> Unfortunately, the c
Hello,
> "To improve our algorithm and make it more robust we need to
understand further what kind of path bias attacks are relevant
here...What nasty attacks can this adversary do?"
An gateway adversary which can filter the network can use guards to
fingerprint you. This requires connecting to t
Hello there,
recently we've been busy specifying various important improvements to entry
guard security. For instance see proposals 250, 241 and ticket #16861.
Unfortunately, the current guard codebase is dusty and full of problems (see
#12466, #12450). We believe that refactoring and cleaning up
15 matches
Mail list logo
