>> As I was saying above, a fixed exit would allow compromise in the time
>> it takes to begin surveillance (times three). We can likely do better
>> than that.
>
> Ok, this was my assumption behind arguing for staggering these rotation
> periods, too. I don't think that having a fixed exit is a g
A. Johnson:
>
> > HS -> Guard_1 -> Guard_2 -> Guard_3 -> RP.
> >
> > The idea is that Guard_1 is a single node that you choose and keep
> > for O(6 months, or as long as possible), but Guard_2 actually comes
> > from a set of 3-6 or so nodes that you keep for O(weeks), and
> > Guard_3 you rotate
> It's interesting to reduce the HS path length, but that would reduce
> the length of the chain that the adversary has to walk, which is bad :/
Yeah, security in this attack model pushes towards a long path.
> The rendezvous model is a bit restricting isn't it :(
Agreed, modifying path selectio
By the way, I actually can think of a good reason to include multiple rotation
speeds: to deal with both your uncertainty about surveillance speed and its
randomness. Suppose that you think it takes somewhere between 3 hours and 1
month, but don’t have a much better guess than that. Then a good
George Kadianakis writes:
> Mike Perry writes:
>
>> A. Johnson:
>>> >> The idea would be that Guard_3 would rotate on the order of hours,
>>> >> Guard_2 would come from a set that is rotated on the order of days
>>> >> (based on the expected duration for the adversary to become
>>> >> Guard_3),
Mike Perry writes:
> A. Johnson:
>> >> The idea would be that Guard_3 would rotate on the order of hours,
>> >> Guard_2 would come from a set that is rotated on the order of days
>> >> (based on the expected duration for the adversary to become
>> >> Guard_3), and Guard_1 would rotate on the orde
> HS -> Guard_1 -> Guard_2 -> Guard_3 -> RP.
>
> The idea is that Guard_1 is a single node that you choose and keep for
> O(6 months, or as long as possible), but Guard_2 actually comes from a
> set of 3-6 or so nodes that you keep for O(weeks), and Guard_3 you
> rotate something like O(hours).
.
A. Johnson:
> >> The idea would be that Guard_3 would rotate on the order of hours,
> >> Guard_2 would come from a set that is rotated on the order of days
> >> (based on the expected duration for the adversary to become
> >> Guard_3), and Guard_1 would rotate on the order of months (based on
> >>
>> The idea would be that Guard_3 would rotate on the order of hours,
>> Guard_2 would come from a set that is rotated on the order of days
>> (based on the expected duration for the adversary to become Guard_3), and
>> Guard_1 would rotate on the order of months (based on the expected
>> duration
>> And yes again. In this model, an ultra-mega-secret HS should use a
>> long chain of guards. Of course, at some point, it is easier to do a
>> congestion attack to identify the first guard being used by the HS.
>> That is still a win, though, in that such an attack takes more
>> technical skill
A. Johnson:
> > It seems to me that we want to defend against (at least) two
> > different attacks here:
> >
> > Sybil attack:
> ...
> > Coercion attack:
>
> Yes, I also am currently thinking about the problem in this way.
>
> > Unfortunately, it doesn't really make sense to add two '5 day
> >
> It seems to me that we want to defend against (at least) two different
> attacks here:
>
> Sybil attack:
...
> Coercion attack:
Yes, I also am currently thinking about the problem in this way.
> Unfortunately, it doesn't really make sense to add two '5 day
> guards' in a circuit, since a Syb
"A. Johnson" writes:
>> As I've suggested before, I really really think you should also analyze
>> an I2P-like scheme where HSs try really hard to maintain path
>> persistence to their RPs for some fixed time period on the order of an
>> hour (but which can be parameterized and analyzed to give t
> As I've suggested before, I really really think you should also analyze
> an I2P-like scheme where HSs try really hard to maintain path
> persistence to their RPs for some fixed time period on the order of an
> hour (but which can be parameterized and analyzed to give the expected
> time for guar
George Kadianakis:
> Roger Dingledine writes:
>
> > On Sat, Sep 13, 2014 at 04:07:13PM +0300, George Kadianakis wrote:
> >> So let's say that along with our guard, we also pick 6 second-tier
> >> guards (middle nodes) that also get pinned for 2-3 months. This makes
> >> us look like this:
> >>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/09/14 15:34, George Kadianakis wrote:
> Michael Rogers writes:
>> Hi George,
>>
>> Could you explain what it means to say that HS traffic isn't
>> counted in the load balancing equations? Why is that so, and can
>> it be changed if that would
Roger Dingledine writes:
> On Sat, Sep 13, 2014 at 04:07:13PM +0300, George Kadianakis wrote:
>> So let's say that along with our guard, we also pick 6 second-tier
>> guards (middle nodes) that also get pinned for 2-3 months. This makes
>> us look like this:
>>
>> -> middle1
>>
Michael Rogers writes:
> On 13/09/14 14:07, George Kadianakis wrote:
>> a) To reduce the ownage probabilities we could pick a single
>> middle node instead of 6. That will greatly improve guard
>> discovery probabilities, and make us look like this:
>>
>> HS -> guard -> middle -> -> RP (where
On Sat, Sep 13, 2014 at 04:07:13PM +0300, George Kadianakis wrote:
> So let's say that along with our guard, we also pick 6 second-tier
> guards (middle nodes) that also get pinned for 2-3 months. This makes
> us look like this:
>
> -> middle1
> -> middle2
> HS -> guard ->
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/09/14 14:07, George Kadianakis wrote:
> a) To reduce the ownage probabilities we could pick a single
> middle node instead of 6. That will greatly improve guard
> discovery probabilities, and make us look like this:
>
> HS -> guard -> middle -
Paul Syverson writes:
> On Fri, Jul 11, 2014 at 08:31:05AM -0400, Ian Goldberg wrote:
>> On Fri, Jul 11, 2014 at 01:44:36PM +0300, George Kadianakis wrote:
>> > Hey Nick,
>> >
>> > this mail is about the schemes we were discussing during the dev
>> > meeting on how to protect HSes against guard
Ian Goldberg writes:
> On Fri, Jul 11, 2014 at 01:44:36PM +0300, George Kadianakis wrote:
>> Hey Nick,
>>
>> this mail is about the schemes we were discussing during the dev
>> meeting on how to protect HSes against guard discovery attacks (#9001).
>>
>> I think we have some ideas on how to off
"Sebastian G. " writes:
> 11.07.2014 14:31, Ian Goldberg:
>> On Fri, Jul 11, 2014 at 01:44:36PM +0300, George Kadianakis wrote:
>>> Hey Nick,
>>>
>>> this mail is about the schemes we were discussing during the dev
>>> meeting on how to protect HSes against guard discovery attacks (#9001).
>>> (.
On Fri, Jul 11, 2014 at 08:31:05AM -0400, Ian Goldberg wrote:
> On Fri, Jul 11, 2014 at 01:44:36PM +0300, George Kadianakis wrote:
> > Hey Nick,
> >
> > this mail is about the schemes we were discussing during the dev
> > meeting on how to protect HSes against guard discovery attacks (#9001).
> >
11.07.2014 14:31, Ian Goldberg:
> On Fri, Jul 11, 2014 at 01:44:36PM +0300, George Kadianakis wrote:
>> Hey Nick,
>>
>> this mail is about the schemes we were discussing during the dev
>> meeting on how to protect HSes against guard discovery attacks (#9001).
>> (...)
HS stands for hidden-service,
On Fri, Jul 11, 2014 at 01:44:36PM +0300, George Kadianakis wrote:
> Hey Nick,
>
> this mail is about the schemes we were discussing during the dev
> meeting on how to protect HSes against guard discovery attacks (#9001).
>
> I think we have some ideas on how to offer better protection against
>
Hey Nick,
this mail is about the schemes we were discussing during the dev
meeting on how to protect HSes against guard discovery attacks (#9001).
I think we have some ideas on how to offer better protection against
such attacks, mainly by keeping our middle nodes more static than we
do currently
27 matches
Mail list logo
