On Sun, May 08, 2016 at 02:04:23AM -0400, Tim Wilson-Brown - teor wrote:
> > ??? Each client will have a cache-microdesc-consensus file with 4
> > relays in it. relay 0, 1 and 2 will always be there and the last one
> > changes each time I start the network.
Are all your relays on just a few
> On 8 May 2016, at 01:52, Xiaofan Li wrote:
>
> About the issue, I've checkout the 0.2.8 commit and tested on that. The
> problem is still there so I looked deeper into it. I've run it many time and
> it seems like once I start restricting path, it becomes undeterministic
> whether the boots
Sorry for the spam, but I have a critical typo on the previous message.
Instead of "with 11 nodes (2 relays) and 2 clients who have path
restriction." I meant 11 nodes (2 authorities) and 2 clients.
On Sun, May 8, 2016 at 1:52 AM, Xiaofan Li wrote:
> Tim,
>
> I'm not sure if Tor is looking for a
Tim,
I'm not sure if Tor is looking for alternative transport protocols like
> QUIC.
>
What if it's a lot faster than TCP on Tor?
> One of the issues is that any modified client is easy to fingerprint.
> So, as with IPv6, we'd need relays to run QUIC and TCP in parallel for
> some time, then cl
Typos:
> used as input to the SHAKE-256 extendable output function (XOF), as
decribed
deScribed
> In the case for relays possessing Ed25519 identity keys (c.f. Tor proposal
> ...
> descriptor (c.f. Tor proposal #264) advertises support for the "Relay"
> ...
> (c.f. Tor proposal #249).
> .
On Sun, 08 May 2016 02:00:51 +0200
Jeff Burdges wrote:
> On Sat, 2016-05-07 at 22:01 +, Yawning Angel wrote:
> > how an adversary will be limited to just this information, and not
> > things that enable a strong attack on it's own like packet timing
> > escapes me
>
> Yes, it's clear that
On Sat, 2016-05-07 at 22:01 +, Yawning Angel wrote:
> how an adversary will be limited to just this information, and not
> things that enable a strong attack on it's own like packet timing
> escapes me
Yes, it's clear that an adversary who can get CPU timing can get packet
timing.
It's not
On Sat, 07 May 2016 23:46:28 +0200
Jeff Burdges wrote:
> On Sat, 2016-05-07 at 13:14 -0700, Watson Ladd wrote:
> > I'm not sure I understand the concern here. An attacker sees that we
> > got unlucky: that doesn't help them with recovering SEED under mild
> > assumptions we need anyway about SHAK
On Sat, 7 May 2016 19:41:59 + (UTC)
lukep wrote:
> Thanks isis for this, it looks really good, I look forward to seeing a
> similar protocol for SIDH! (and X25519+NEWHOPE+SIDH !)
When there is a sufficiently fast SIDH implementation, it might be worth
considering (MS Research's is less slow t
On Sat, 2016-05-07 at 13:14 -0700, Watson Ladd wrote:
> I'm not sure I understand the concern here. An attacker sees that we
> got unlucky: that doesn't help them with recovering SEED under mild
> assumptions we need anyway about SHAKE indistinguishability.
We're assuming the adversary controls a
On Sat, 2016-05-07 at 19:41 +, lukep wrote:
> It's hard to guarantee that any fixed, finite amount of SHAKE
> output will be sufficient for any rejection sampling method
> like gen_a.
Isn't some small multiple usually enough? I think 1024 is large enough
to tend towards the expected 42%ish f
On Sat, May 7, 2016 at 12:41 PM, lukep wrote:
> Jeff Burdges writes:
>
>>
>> On Fri, 2016-05-06 at 19:17 +, isis wrote:
>>
>> > --- Description of the Newhope internal functions ---
>> >
>> > gen_a(SEED seed) receives as input a 32-byte (public) seed. It expands
>> > this seed through
Jeff Burdges writes:
>
> On Fri, 2016-05-06 at 19:17 +, isis wrote:
>
> > --- Description of the Newhope internal functions ---
> >
> > gen_a(SEED seed) receives as input a 32-byte (public) seed. It expands
> > this seed through SHAKE-128 from the FIPS202 standard. The output of
SHA
> On 7 May 2016, at 05:17, isis wrote:
>
> ...
>
> Let `ID` be a router's identity key taken from the router microdescriptor.
> In the case for relays possessing Ed25519 identity keys (c.f. Tor proposal
> #220), this is a 32-byte string representing the public Ed25519 identity key.
> For backwa
Just a brief aside about post-quantum handshake approaches that
seemingly do not work.
I suppose Tor folk remember the article Using Sphinx to Improve
Onion Routing Circuit Construction by Aniket Kate and Ian Goldberg.
As key sizes are a main obstacle to a post-quantum key exchange,
one might
15 matches
Mail list logo
