Hi,
First, thanks a lot both of you for your in-depth comments, I know it takes
time,
but they've been very helpful!
Then I mean to ask you about what you said regarding the fallback
directory keys. So keys are not embedded but only hashes, OK. As you
pointed out, CoSi would need to download ful
> On 6 May 2016, at 09:34, Xiaofan Li wrote:
>
> Hi all,
> We've finished building TOR on QUIC and everything works fine with chutney.
> However, we have an issue with the node availability when we test on real
> networks. We need this to work in order to evaluate the effect of HOL
> blocking
> On 6 May 2016, at 19:07, Nicolas Gailly wrote:
>
> Hi,
>
> First, thanks a lot both of you for your in-depth comments, I know it takes
> time,
> but they've been very helpful!
>
> Then I mean to ask you about what you said regarding the fallback
> directory keys. So keys are not embedded bu
On Fri, May 06, 2016 at 07:13:04PM +1000, Tim Wilson-Brown - teor wrote:
> On 6 May 2016, at 09:34, Xiaofan Li wrote:
> > ??? However, our real issue is when I restrict the path selection to 3
> > pre-determined nodes for all exit circuits, the client will not reach 100%
> > anymore and keep
> On 6 May 2016, at 21:52, Roger Dingledine wrote:
>
>> (Normally, a client won't re-use any of its 3 guards as a middle or
>> exit. TestingTorNetwork disables this behaviour.
>
> Tim: I think this statement might be wrong? Tor picks its exit first,
> then picks a current guard that doesn't ove
Hi everyone,
this is the first status report on the Tails Server GSoC project. I
officially began working on it on April 25th, although I already did
some work in the weeks before.
This is what I have done so far:
* Updating the blueprint of the Tails Server [1]
* Implementing two iterations of
Thanks for the replies!
1. About the name:
Thanks for the headsup! We'll definitely pay attention to the trademark
rules when we publish our results. We are not planning to roll out our own
version of Tor. I think our most important goal is probably: demonstrate a
possibility of UDP-based protocol
Hello,
Peter (in CC) and I have recently composed a draft proposal for a new Tor
handshake. It's a hybrid handshake combining Tor's current X25519-based NTor
handshake with the NewHope lattice-based key exchange, in order to protect the
secrecy of Tor connections today from an attacker with a qua
On Fri, 6 May 2016 19:17:11 +
isis wrote:
> Both parties check that none of the EXP() operations produced the
> point at infinity. [NOTE: This is an adequate replacement for
> checking Y for group membership, if the group is Curve25519.]
>
> [XXX: This doesn't sound exactly right. You nee
On Fri, 6 May 2016 19:17:11 +
isis wrote:
> [XXX We think we want to omit the final hashing in the production
> of NTOR_KEY here, and instead put all the inputs through SHAKE-256.
> --isis, peter]
>
> [XXX We probably want to remove ID and B from the input to the
> shared key material, si
> On 7 May 2016, at 05:10, Xiaofan Li wrote:
>
> Thanks for the replies!
>
> 1. About the name:
> Thanks for the headsup! We'll definitely pay attention to the trademark rules
> when we publish our results. We are not planning to roll out our own version
> of Tor. I think our most important g
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
> SHAKE-128
> is considered a sequence
12 matches
Mail list logo
