On Fri, Oct 16, 2015 at 1:58 AM, Karsten Loesing wrote:
> It seems that the introduction of ed25519 identities will allow us to
> find a format that doesn't suffer from shortcomings like this one. Be
> sure to watch that process and raise your concerns while they can
> still be considered.
Where
I started using Trac a bit more and the slowness is a little unpleasant.
Here are some stats:
http://www.webpagetest.org/result/151019_RW_387/
The time-to-first-byte is *painful* on both the first load as well as
reload.
Are there some ways we could improve this? If it's sever-power I'm willing
Nick Mathewson transcribed 3.1K bytes:
> On Tue, Oct 13, 2015 at 8:05 AM, Mike Perry wrote:
>> Nick Mathewson:
> [...]
>>> (How fast is it?
>>>
>>> To encrypt a 509-byte relay cell with a 16 byte nonce and 32 bytes
>>> of additional data, AEZ only uses 360 aes rounds. This is the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18/10/15 23:50, Damian Johnson wrote:
>> Damian and I sat down yesterday at the dev meeting to talk about
>> doing a comparison of the various descriptor-parsing libraries
>> with respect to capabilities, run-time performance, memory usage,
>> etc.
> The only thing that's wrong is that zoossh can detect types by looking
> at @type.
Thanks! Fix pushed, it'll show up in a few minutes.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Sun, Oct 18, 2015 at 02:50:47PM -0700, Damian Johnson wrote:
> > Damian and I sat down yesterday at the dev meeting to talk about doing
> > a comparison of the various descriptor-parsing libraries with respect
> > to capabilities, run-time performance, memory usage, etc.
>
> Hi Karsten, started
> Damian and I sat down yesterday at the dev meeting to talk about doing
> a comparison of the various descriptor-parsing libraries with respect
> to capabilities, run-time performance, memory usage, etc.
Hi Karsten, started moving this forward with the easy bit: a table
comparing capabilities. Mi
On Sun, 18 Oct 2015 19:20:47 +0200
Rob van der Hoeven wrote:
> I never adjust the size of the TCP window, that's correct. The code
> only sends an ACK for data that is *removed* from the buffer. If data
> is added to the buffer, the amount of data the TCP-client is allowed
> to send decreases. Ev
On Sun, 2015-10-18 at 14:43 +, Yawning Angel wrote:
> > Congestion control is used to prevent dropped segments. This can not
> > happen on the User Space <-> kernel connection of a tun interface. The
> > TCP-window flow control prevents this.
>
> Hm. Your code never shrinks the advertised wi
On Sun, 18 Oct 2015 13:08:01 +0200
Rob van der Hoeven wrote:
[snip]
> When I was researching my idea I came across lwIP and was planning to
> use it. Unfortunately I could not find documentation. It's not on the
> project homepage and the wikia pages were not helpful too. What I
> needed was the
Razvan Dragomirescu:
> Ivan, if I understand
> https://onionbalance.readthedocs.org/en/latest/design.html#next-generation-onion-services-prop-224-compatibility
> correctly, the setup I've planned will no longer work once Tor switches to
> the next generation hidden services architecture, is this co
Razvan Dragomirescu:
> Thank you Ivan!
You're welcome!
> Ah, I understand now! That actually makes perfect sense for my application.
> If I understand it correctly, I can simply let Tor register the HS by
> itself (using a random HS name/key), then fetch the introduction points and
> keys and re-r
On Fri, 2015-10-16 at 15:31 +, Yawning Angel wrote:
> Cute. The networking part works in a near-identical manner Orbot's
> Android VPN mode, under the hood, except they opted to use a 3rd party
> implementation (that bundles lwIP IIRC).
>
Interesting...
> Why did you write your own IP/ICMP/
Ivan, if I understand
https://onionbalance.readthedocs.org/en/latest/design.html#next-generation-onion-services-prop-224-compatibility
correctly, the setup I've planned will no longer work once Tor switches to
the next generation hidden services architecture, is this correct? Will
there be any back
Thank you s7r! I think I'm going to start by simply using a mechanism
similar to OnionBalance - I'm going to let Tor do its HS registration with
a random HS name (and with a key that the host knows), then read the
introduction points and keys and re-register them (a la OnionBalance) with
a new HS n
Thank you Ivan!
On Sun, Oct 18, 2015 at 1:44 AM, Ivan Markin wrote:
> Not exactly. The trick is that keys are not the same. For more details
> have a look at the specifications [1]. There is a "permanent key"
> ("holds the name", signs descriptors) and an "onion key" [2] for each
> Introduction
16 matches
Mail list logo
