Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Enable hardware crypto acceleration on your Via Nano dedi - Page 2
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.

Enable hardware crypto acceleration on your Via Nano dedi

2

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 :/

  • @Giulio said:
    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.

    Thanked by 1black
  • MaouniqueMaounique Host Rep, Veteran

    Dylan said: You got your Kidechire on November 28th, right, and I think you said in another thread you set up Tor a few days after that? A load drop on December 10th would seem to fit the new relay timeline pretty closely.

    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 :)

  • blackblack Member
    edited December 2014

    linuxthefish said: @black add "HardwareAccel 1" in your torrc.

    Thanks, that fixed tor :)

    Edit: nevermind, it crashed again for the same reason.

  • @jaakka said:
    sepei, could be that its already in the tree

    openssl engine padlock should not give out an error

    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

  • @Maounique said:
    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 :)

    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.

  • coolicecoolice Member
    edited January 2015

    @sepei said:
    How to do thsi on centos?

    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

     dd if=/dev/zero count=100 bs=1M | ssh -c aes128-cbc localhost "cat >/dev/null"
    root@localhost's password: 
    100+0 records in
    100+0 records out
    104857600 bytes (105 MB) copied, 7,82336 s, 13,4 MB/s 
    dd if=/dev/zero count=100 bs=1M | ssh -c aes128-cbc localhost "cat >/dev/null"
    root@localhost's password: 
    100+0 records in
    100+0 records out
    104857600 bytes (105 MB) copied, 3,58612 s, 29,2 MB/s 

    fast pasting password with shift + ins

  • kidechire with a fresh installed debian system is showing me this:

    root@server:~# openssl speed -evp aes-128-cbc -engine padlock
    engine "padlock" set.
    Doing aes-128-cbc for 3s on 16 size blocks: 15563467 aes-128-cbc's in 3.00s
    Doing aes-128-cbc for 3s on 64 size blocks: 9630568 aes-128-cbc's in 2.99s
    Doing aes-128-cbc for 3s on 256 size blocks: 3437139 aes-128-cbc's in 3.00s
    Doing aes-128-cbc for 3s on 1024 size blocks: 1063825 aes-128-cbc's in 2.97s
    Doing aes-128-cbc for 3s on 8192 size blocks: 154125 aes-128-cbc's in 3.00s
    OpenSSL 1.0.1e 11 Feb 2013
    built on: Thu Jan  8 21:47:50 UTC 2015
    options:bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) aes(partial) blowfish(idx) 
    compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -march=i686 -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
    The 'numbers' are in 1000s of bytes per second processed.
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    aes-128-cbc      83005.16k   206139.25k   293302.53k   366786.80k   420864.00k
    

    Does it mean the openssl/libssl is already padlock enabled? If not, whats the way to find out?

  • rm_rm_ IPv6 Advocate, Veteran
    edited February 2015

    @akb what do you get in

    dd if=/dev/zero bs=1M count=512 | openssl sha256

    Should be ~230MB/sec.

  • root@server:~# dd if=/dev/zero bs=1M count=512 | openssl sha256
    512+0 records in
    512+0 records out
    536870912 bytes (537 MB) copied, 10.9468 s, 49.0 MB/s
    (stdin)= 9acca8e8c22201155389f65abbf6bc9723edc7384ead80503839f49dcc56d767
    

    It mean hardware acceleration isn't getting used? I thought:

    root@server:~#  openssl engine padlock
    (padlock) VIA PadLock (no-RNG, ACE)
    

    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.

  • NyrNyr Community Contributor, Veteran

    @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?

    HardwareAccel 1
    AccelName padlock
    
    [notice] Default OpenSSL engine for AES-128-ECB is VIA PadLock (no-RNG, ACE) [padlock]
    [notice] Default OpenSSL engine for AES-128-CBC is VIA PadLock (no-RNG, ACE) [padlock]
    [notice] Default OpenSSL engine for AES-256-CBC is VIA PadLock (no-RNG, ACE) [padlock]
    

    .. but the CPU load is the same or even worse on CentOS (padlock enabled) in comparison to Ubuntu (padlock not enabled). ... :(

  • NyrNyr Community Contributor, Veteran

    I don't remember the specifics now, but didn't have much luck with PadLock and Tor either.

    Thanked by 14n0nx
  • @4n0nx I tried and failed :(

    Thanked by 14n0nx
  • 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 :(

  • rm_rm_ IPv6 Advocate, Veteran
    edited September 2015

    OpenSSL does not support Padlock's SHA acceleration at all.

    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).

  • xyzxyz Member
    edited September 2015

    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?

  • rm_rm_ IPv6 Advocate, Veteran

    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...

    #DataDirectory /var/lib/tor
    PidFile /var/run/tor/tor.pid
    RunAsDaemon 1
    #User debian-tor
    
    #ControlSocket /var/run/tor/control
    #ControlSocketsGroupWritable 1
    
    #CookieAuthentication 1
    #CookieAuthFileGroupReadable 1
    #CookieAuthFile /var/run/tor/control.authcookie
    
    Log notice file /var/log/tor/log

    Then edit your /etc/tor/torrc and add this...

    HardwareAccel 1
    AccelName padlock
    User root

    Effectively running Tor as root... Then it starts up just fine and while it does print some errors:

    Sep 20 12:04:01.000 [notice] Tor 0.2.6.10 (git-71459b2fe953a1c0) opening log file.
    Sep 20 12:04:01.000 [notice] Not disabling debugger attaching for unprivileged users.
    Sep 20 12:04:01.000 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option.
    Sep 20 12:04:01.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't.
    Sep 20 12:04:01.000 [notice] Default OpenSSL engine for RSA is RSAX engine support [rsax]
    Sep 20 12:04:01.000 [notice] Default OpenSSL engine for SHA1 is VIA PadLock: RNG ACE2 PHE NANO  [padlock]
    Sep 20 12:04:01.000 [notice] Default OpenSSL engine for AES-128-ECB is VIA PadLock: RNG ACE2 PHE NANO  [padlock]
    Sep 20 12:04:01.000 [notice] Default OpenSSL engine for AES-128-CBC is VIA PadLock: RNG ACE2 PHE NANO  [padlock]
    Sep 20 12:04:01.000 [notice] Default OpenSSL engine for AES-256-CBC is VIA PadLock: RNG ACE2 PHE NANO  [padlock]
    Sep 20 12:04:01.000 [warn] Unhandled OpenSSL errors found at ../src/common/tortls.c:479: 
    Sep 20 12:04:01.000 [warn] TLS error: conflicting engine id (in engine routines:ENGINE_LIST_ADD:---)
    Sep 20 12:04:01.000 [warn] TLS error: internal list error (in engine routines:ENGINE_add:---)

    ...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).

  • rm_rm_ IPv6 Advocate, Veteran
    edited September 2015

    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:

    chown root:root -R /var/lib/tor/ /var/run/tor/ /var/log/tor/
  • rm_rm_ IPv6 Advocate, Veteran

    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.

    rm_ said: Via Nano used in Online.net Kidechires and SCGen2 does support the Padlock extensions as well. In my tests enabling them in OpenSSL improves SHA1 performance by almost 4x, and drops the CPU load from HTTPS by 3x.

    See my howto on rebuilding OpenSSL in Debian with Padlock support.

    Let me know if it worked or not for you, also if it needs any clarifications or corrections

  • It does not improve Tor performance.. at least not for me..

  • GM2015 said: Do you think this would reduce the cpu load that comes with a danted's socks proxy encryption overhead?

    No.

    Thanked by 1GM2015
  • netomxnetomx Moderator, Veteran

    hey @rm_ , have you tried compiling Tor without optimizations? I have had problems with segmentation faults when optimizing the compiled code.

  • rm_rm_ IPv6 Advocate, Veteran
    edited September 2016

    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:

    openssl speed -evp aes-256-cbc
    i5-3570S:
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    aes-256-cbc     503045.35k   527675.33k   533090.56k   534551.55k   534749.18k
    
    VIA Nano software:
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    aes-256-cbc      44501.64k    47309.02k    49103.10k    48988.44k    49356.09k
    
    VIA Nano hardware:
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    aes-256-cbc      74678.28k   248020.33k   489234.82k   640749.64k   711964.72k
    
  • Also faster than i7 3770:

    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    aes-256-cbc     494315.77k   539460.12k   546567.79k   546077.70k   547512.32k
    
  • lovemindsloveminds Member
    edited September 2016

    @hotsnow said:
    sounds good :p

    Are u have pirated cheverto copy...Can u give me one

Sign In or Register to comment.