Hi,
I am struggling setting up aes-in support with Ubuntu 12.04 LTS. I enabled
aes in bios. cat /proc/cpuinfo shows the aes flag.
#lsmod |grep aes
aesni_intel55664 0
cryptd 20530 1 aesni_intel
aes_x86_64 17208 1 aesni_intel
shows that the module is lo
On 8/15/12, tor-admin wrote:
> Hi,
>
> I am struggling setting up aes-in support with Ubuntu 12.04 LTS. I enabled
> aes in bios. cat /proc/cpuinfo shows the aes flag.
>
> #lsmod |grep aes
> aesni_intel55664 0
> cryptd 20530 1 aesni_intel
> aes_x86_64 17208
On Aug 15, 2012, at 5:18 AM, k...@damnfbi.tk wrote:
> Can anyone explain how to get the Unnamed flag for my node changed over to
> Named?
> -kupo
The only way is to wait while the name mapping expires.
___
tor-relays mailing list
tor-relays@lists.tor
On Wednesday, August 15. 2012, 10:43:05 Robert Ransom wrote:
> > #openssl version
> > OpenSSL 1.0.1 14 Mar 2012
>
> OpenSSL 1.0.1 uses AES-NI by default if it is available.
>
Does this mean that the command
#openssl engine
(rsax) RSAX engine support
(dynamic) Dynamic engine loading support
does
2012/8/15 :
> Can anyone explain how to get the Unnamed flag for my node changed over to
> Named?
> -kupo
Cannot find the criteria right now, but if IIRC :
- You must have your node name and key associated for ~20 days.
- No other relay must have the same name during the last 6 months.
--
Ex
On Wed, Aug 15, 2012 at 11:55:55AM +0800, Lorenz Kirchner wrote:
> I'm not a tor expert but I am in China and have been using tor... I brought
> this up before and I still feel that tor would benefit from having special
> (entry)relays inside the GFW that have a reliable link to relays outside the
On 15.08.2012 05:18, k...@damnfbi.tk wrote:
> Can anyone explain how to get the Unnamed flag for my node changed over
> to Named?
> -kupo
https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1522
[...] Newer Naming authorities run a script that registers routers
in their mapping fil
On 15.08.2012 13:03, tor-admin wrote:
> Does this mean that the command
>
> #openssl engine
> (rsax) RSAX engine support
> (dynamic) Dynamic engine loading support
>
> does not need to show a line with "(aesni) Intel AES-NI engine" as described
> here at Torservers:
> https://www.torservers.net
On Wednesday, August 15. 2012, 14:33:34 Moritz Bartl wrote:
> Yes, that is correct. That is what " OpenSSL 1.0.1 does not come with an
> extra module and should directly support AES-NI. " in the wiki was meant
> to say. I will revise the section a bit.
Thanks for clarification. I already supposed
I guess, that would require a modification of the path selection on the
> clients
> side. Usually, Tor clients randomly pick relays weighted by bandwidth.
> Unless
> the Chinese relays would provide an enormous amount of bandwidth, they
> would
> barely get selected by clients which leads to a poor
Hi Philipp
> Perhaps it's better to focus on improved bridge distribution strategies
> [0] and
> hard-to-block transport protocols [1]. Also, that would be a universal
> solution
> which would also help in other countries and not a specific - and probably
> hard
> to maintain - Chinese-only solut
Hi Loz,
On Wed, Aug 15, 2012 at 11:00:11PM +0800, Lorenz Kirchner wrote:
>> I guess, that would require a modification of the path selection on the
>> clients
>> side. Usually, Tor clients randomly pick relays weighted by bandwidth.
>> Unless
>> the Chinese relays would provide an enormous amount
On Wed, Aug 15, 2012 at 11:42:08PM +0800, Lorenz Kirchner wrote:
>> Perhaps it's better to focus on improved bridge distribution strategies [0]
>> and
>> hard-to-block transport protocols [1]. Also, that would be a universal
>> solution
>> which would also help in other countries and not a specific
Hi,
At torservers.net, we run some large exit relays with an "allow all
except port 25" policy.
These are statistics from ARM showing exit port statistics of a fast
exit running for seven hours at 30-40 MB/s:
443 HTTPS 17650 (%55)
80 HTTP10625 (%33)
8344739 (%2
Thus spake Moritz Bartl (mor...@torservers.net):
> At torservers.net, we run some large exit relays with an "allow all
> except port 25" policy.
>
> These are statistics from ARM showing exit port statistics of a fast
> exit running for seven hours at 30-40 MB/s:
>
> 443 HTTPS 17650 (%55)
On Wednesday, August 15, 2012 4:44pm, "Mike Perry"
said:
[snip]
> Here's the read and write statistics from the ExtraInfo descriptors from
> a handful of the fastest default-policy and reduced-policy relays:
>
> Default exit lumumba read 819.7M
>other: 66.5% 80: 22.7% 443: 5.1% 51413: 1.4% 6
Thus spake Steve Snyder (swsny...@snydernet.net):
> On Wednesday, August 15, 2012 4:44pm, "Mike Perry"
> said:
> > Here's the read and write statistics from the ExtraInfo descriptors
> > from a handful of the fastest default-policy and reduced-policy
> > relays:
> >
>
> Pardon my tangent, but: T
On Wed, Aug 15, 2012 at 10:21:18PM +0200, Moritz Bartl wrote:
> At torservers.net, we run some large exit relays with an "allow all
> except port 25" policy.
>
> These are statistics from ARM showing exit port statistics of a fast
> exit running for seven hours at 30-40 MB/s:
>
> 443 HTTPS 17
On Thu, Aug 16, 2012 at 3:23 AM, Philipp Winter wrote:
> Yes, assuming the users would not give up out of frustration before :-) We
> can
> actually do the math: According to [0], at the moment the Tor network has
> an
> advertised bandwidth of 3000 MiB/s. Let's assume that all Chinese relays
>
19 matches
Mail list logo
