-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 7/19/2015 9:26 AM, Roger Dingledine wrote:
> On Sat, Jul 18, 2015 at 03:11:26AM +0300, s7r wrote:
>> I still see the third hop (speaking from hidden service server
>> start point) is the weak part here. An attacker can connect to a
>> hidden servi
On Sat, Jul 18, 2015 at 03:11:26AM +0300, s7r wrote:
> I still see the third hop (speaking from hidden service server start
> point) is the weak part here. An attacker can connect to a hidden
> service at his malicious relay selected as rendezvous. Before you know
> it, all relays in third_guard_se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Your points are correct and I cannot agree more. I don't think that an
adversary running his own relays is less of a threat, just that it
depends on the adversary and the context. Running his own relays might
be the more expensive and time consu
I agree with most of what you said regarding the threat of a targeted observer.
What I disagree with is that an adversary running his own relays is less of a
threat. Running relays is trivial, and running 5% of the guards is fairly cheap
(I estimate ~$3000/month (please ask for details)). If you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 7/18/2015 12:49 AM, A. Johnson wrote:
>
> Not having the third guards be selected by every second guard makes
> sense when you consider that the adversary may not be able to
> compromise all relays equally. That was not a consideration I had
> in
>> Here's another crazy idea that would potentially bring this Vanguards
>> idea closer to "Virtual Circuits": What if you divided your third-level
>> Vanguards into NUM_SECOND_GUARDS isolated buckets, and mapped exactly
>> one these buckets to each of your second-level guards?
...
>> That way, i
Comments inline.
On 7/16/2015 7:26 AM, Mike Perry wrote:
> George Kadianakis:
>> Hello,
>>
>> I'm attaching a proposal draft that should help us defend against
>> guard discovery attacks.
>>
>> There are a few pieces left unfinished (see the XXXs) but I decided to
>> release early and release ofte
George Kadianakis:
> Hello,
>
> I'm attaching a proposal draft that should help us defend against
> guard discovery attacks.
>
> There are a few pieces left unfinished (see the XXXs) but I decided to
> release early and release often for the sake of moving forward with
> this. I consider this iss
On Sat, Jul 11, 2015 at 03:50:16PM +0300, s7r wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> I find it better to add a new consensus flag called 'Vanguard' which
> will be assigned to relays with lower requirements than the 'Guard'
> (less bandwidth, just the Stable flag). We will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I find it better to add a new consensus flag called 'Vanguard' which
will be assigned to relays with lower requirements than the 'Guard'
(less bandwidth, just the Stable flag). We will then select
second_guard_set and third_guard_set from relays havi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
Estimations look good.
I think second_guard_set & third_guard_set should not have the same
requirements like how any Tor client chooses the guard (first hop). We
can select second guards and third guards by requiring for example
just Stable
Hello,
I'm attaching a proposal draft that should help us defend against
guard discovery attacks.
There are a few pieces left unfinished (see the XXXs) but I decided to
release early and release often for the sake of moving forward with
this. I consider this issue very important and any feedback
12 matches
Mail list logo
