New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
My tor also crash after the patch. As other people said in the thread the test went from 35/30 MB/s so 190/210 MB/s. However now tor crash a while after startup with no error messages, even in the debug log
If you install tor from their repos, you'll see what I pasted in /var/log/tor/log
@black add "HardwareAccel 1" in your torrc.
I understand it will not be stable, but it stayed down for 3 days or so, I don't remember having this large drop before, lets hope it was that
Thanks, that fixed tor
Edit: nevermind, it crashed again for the same reason.
Do you mena its already in my openssl. If that was that you wanted to say I zhink no. I'm getting arround 45MB/s. So again how i can do this on centos
Hopefully! My experience setting up a few new relays lately is that Tor can be very oddly inconsistent. In the case of two identical servers on the same network, one became a guard after 4 days (which I thought was supposed to be impossible), while the other took almost 3 weeks.
A little bit necro posting but not a lot
for centos it is even simple just add few lines to config
http://www.linuxtopia.org/online_books/rhel6/rhel_6_security_guide/rhel_6_security_ch03s07.html
~3 times the speed
fast pasting password with shift + ins
kidechire with a fresh installed debian system is showing me this:
Does it mean the openssl/libssl is already padlock enabled? If not, whats the way to find out?
@akb what do you get in
Should be ~230MB/sec.
It mean hardware acceleration isn't getting used? I thought:
And 'engine "padlock" set.' in the output of above command is reflecting the use of HA by OpenSSL.
Is there a stable solution for Tor now? I'd like to push a little bit more bandwidth on my online.net boxes, they don't manage to do more than 10TB/month.
@tr1cky
Then you are doing something wrong. I do nearly 30TB with no hardware acceleration.
I did set up acceleration, but had problems with Tor itself (don't really remember what happened, but not easily fixable). With CentOS 7, native support is there, no need to recompile OpenSSL.
Has anyone tried this with Tor?
.. but the CPU load is the same or even worse on CentOS (padlock enabled) in comparison to Ubuntu (padlock not enabled). ...
I don't remember the specifics now, but didn't have much luck with PadLock and Tor either.
@4n0nx I tried and failed
facepalms
I could not find it the tens of times I have searched, but now I just found this:
https://www.mail-archive.com/[email protected]/msg74018.html
Looks like Tor prefers AES128-GCM, which padlock does not support -> GCM has to be disabled. Then it still doesn't work because somehow OpenSSL does not work with padlock the way it should ("SHA calls"?). The "bug" was closed as "not a bug".
This is only a TL;DR;DR (as in I did not read it all either).
So much time wasted
This doesn't sound right, as my primary way of testing if Padlock patched OpenSSL has been installed correctly is actually "openssl sha256"... It's 4 times faster with padlock (230 MB/sec vs 60 MB/sec).
I don't know specifically about Tor, but acceleration (i.e. using an alternative engine) only works if the application makes calls via EVP. If calls are being made direct to the default SHA implementation, it doesn't go through EVP and hence doesn't use the Padlock engine.
If you're bothered to, it should be possible to patch the source code to make calls through EVP (assuming that this is the issue).
At least as of 2006, EncFS did not support the Padlock engine.
Does anybody have more recent data on this?
So the latest thing I found is that Tor crashes with a "Segmentation fault" almost immediately after it's been started it in its default mode, but if you edit
/usr/share/tor/tor-service-defaults-torrc
and comment out most of the lines like this...Then edit your
/etc/tor/torrc
and add this...Effectively running Tor as
root
... Then it starts up just fine and while it does print some errors:...it does not crash even after some 30-40 minutes now, doing a little bit of traffic (will take some time to recover from all the restarts during my experimentation), using about 10% CPU, most importantly there finally appears to be a way to at least have patched OpenSSL installed and have working Tor (even if Tor won't be accelerated by it).
Also if you have decided to settle on running a configuration like this, then you can go back into
/usr/share/tor/tor-service-defaults-torrc
, uncomment everything you commented there, and then run:Actually nevermind, the above turned out to be just a side effect of resetting the relay fingerprint. Still, now we know it doesn't crash right away after getting a new relay identity.
Hey Roman,
Do you think this would reduce the cpu load that comes with a danted's socks proxy encryption overhead?
The CPU is constantly at 100% with a load of 3+.
The kidechire's running a LNMP stack too like a champ.
It does not improve Tor performance.. at least not for me..
No.
hey @rm_ , have you tried compiling Tor without optimizations? I have had problems with segmentation faults when optimizing the compiled code.
I have updated the patches in my Padlock HOWTO so it now works on Debian Jessie.
Also did some peformance testing. The Nano with Padlock is faster at AES than a 3.7GHz i5-3570S:
Also faster than i7 3770:
Are u have pirated cheverto copy...Can u give me one