Roger Dingledine:
> On Wed, Apr 11, 2018 at 11:15:44AM +, Mike Perry wrote:
> > > To be clear, the design I've been considering here is simply allowing
> > > reuse between the guard hop and the final hop, when it can't be avoided. I
> > > don't mean to allow the guard (or its family) to show up
Mike Perry:
> Heyo.
>
> We're going to have a meeting to discuss Proposal 291. See this thread:
> https://lists.torproject.org/pipermail/tor-dev/2018-April/013053.html
Ok, we had this meeting. High level (ammended) action items are:
1. Use patches in https://trac.torproject.org/projects/tor/tick
Hi there!
Two new releases are available at:
https://dist.torproject.org/onionoo/6.0-1.13.0/
https://dist.torproject.org/metrics-lib/2.3.0/
This Onionoo release provides the announced major version change to 6.0
Protocol change (also summarized in [0], [1]):
Change the "exit_addresses"
> Date: Wed, 18 Apr 2018 16:53:59 +0300
> From: George Kadianakis
>
> In this case, we can't use S as the replay cache index since the
> attacker can mutate it and still get the sig to verify. Can we use R as
> the replay cache index then? Can an attacker given (R,S) find (R',S')
> such that the
[Warning: recovering from illness. Brain may not be operating at
nominal capacity. :-p ]
On Wed, Apr 18, 2018 at 04:53:59PM +0300, George Kadianakis wrote:
> Thanks for the help!
>
> Hmm, so everyone gets a shot at a single malleability "attack" with
> everye d25519 sig? What's the point of the
Watson Ladd writes:
> On Wed, Apr 18, 2018 at 6:15 AM, George Kadianakis
> wrote:
>> Hello Ian, isis, and other crypto people around here!
>>
>> Here is an intro: In HSv3 we've been using revision counters
>> (integers++) to do HS desc replay protection, so that bad HSDirs cannot
>> replay old
On Wed, Apr 18, 2018 at 6:15 AM, George Kadianakis wrote:
> Hello Ian, isis, and other crypto people around here!
>
> Here is an intro: In HSv3 we've been using revision counters
> (integers++) to do HS desc replay protection, so that bad HSDirs cannot
> replay old descs to other HSDirs. We recent
Hello Ian, isis, and other crypto people around here!
Here is an intro: In HSv3 we've been using revision counters
(integers++) to do HS desc replay protection, so that bad HSDirs cannot
replay old descs to other HSDirs. We recently learned that this is a bad
idea from a scalability prespective (m
On Wed, Apr 11, 2018 at 11:15:44AM +, Mike Perry wrote:
> > To be clear, the design I've been considering here is simply allowing
> > reuse between the guard hop and the final hop, when it can't be avoided. I
> > don't mean to allow the guard (or its family) to show up as all four
> > hops in t
