[tor-bugs] #15503 [Tor]: VIA PadLock suupport does not work.
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sun Mar 29 12:45:05 UTC 2015
#15503: VIA PadLock suupport does not work.
-------------------------+------------------------------------
Reporter: toyboy | Owner:
Type: defect | Status: new
Priority: major | Milestone: Tor: 0.2.7.x-final
Component: Tor | Version: Tor: unspecified
Keywords: VIA PadLock | Actual Points:
Parent ID: | Points:
-------------------------+------------------------------------
I have enabled VIA PadLock support in TOR by adding the following lines to
torrc config file:
HardwareAccel 1
AccelName padlock
Since TOR prefers AES-128-GCM over AES-128/256-CBC I have disabled all
AES-GCM algirithms in src/common/ciphers.inc file - this is required to
test Via PadLock.
I am aware that AES-GCM is more secure than AES-CBC but AES-GCM is NOT
supported by VIA PadLock.
After this modification I see in tcpdump that client and server agreed to
use AES-256-CBC (0xc014) which is supported by VIA Padlock.
During startup in debug log file created by TOR I see the following
messages:
...
Mar 29 14:09:39.000 [notice] Tor 0.2.7.0-alpha-dev (git-4e4ee768fb796f5d)
opening log file.
Mar 29 14:09:39.692 [notice] Tor v0.2.7.0-alpha-dev (git-4e4ee768fb796f5d)
running on Linux with Libevent 2.0.19-stable, OpenSSL 1.0.1e and Zlib
1.2.7.
Mar 29 14:09:39.693 [notice] Tor can't help you if you use it wrong! Learn
how to be safe at https://www.torproject.org/download/download#warning
Mar 29 14:09:39.695 [notice] This version is not a stable Tor release.
Expect more bugs than usual.
Mar 29 14:09:39.697 [notice] Read configuration file "/etc/tor/torrc-
test".
Mar 29 14:09:39.720 [notice] Opening Socks listener on 127.0.0.1:9050
Mar 29 14:09:39.000 [notice] Not disabling debugger attaching for
unprivileged users.
Mar 29 14:09:39.000 [notice] Parsing GEOIP IPv4 file /tmp/tor-
git/share/tor/geoip.
Mar 29 14:09:40.000 [notice] Parsing GEOIP IPv6 file /tmp/tor-
git/share/tor/geoip6.
Mar 29 14:09:40.000 [notice] Default OpenSSL engine for SHA1 is VIA
PadLock: RNG ACE2 PHE PMM [padlock]
Mar 29 14:09:40.000 [notice] Default OpenSSL engine for AES-128-ECB is VIA
PadLock: RNG ACE2 PHE PMM [padlock]
Mar 29 14:09:40.000 [notice] Default OpenSSL engine for AES-128-CBC is VIA
PadLock: RNG ACE2 PHE PMM [padlock]
Mar 29 14:09:40.000 [notice] Default OpenSSL engine for AES-256-CBC is VIA
PadLock: RNG ACE2 PHE PMM [padlock]
Mar 29 14:09:41.000 [notice] Bootstrapped 0%: Starting
Mar 29 14:09:42.000 [notice] Bootstrapped 80%: Connecting to the Tor
network
Mar 29 14:09:44.000 [notice] Bootstrapped 85%: Finishing handshake with
first hop
Mar 29 14:09:44.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Mar 29 14:09:45.000 [notice] Tor has successfully opened a circuit. Looks
like client functionality is working.
Mar 29 14:09:45.000 [notice] Bootstrapped 100%: Done
...
Additionally I have executed openssl quick test:
$ openssl speed -engine padlock -evp aes-256-cbc
engine "padlock" set.
Doing aes-256-cbc for 3s on 16 size blocks: 11632391 aes-256-cbc's in
2.38s
Doing aes-256-cbc for 3s on 64 size blocks: 8720103 aes-256-cbc's in 2.33s
Doing aes-256-cbc for 3s on 256 size blocks: 4521883 aes-256-cbc's in
2.28s
Doing aes-256-cbc for 3s on 1024 size blocks: 1642508 aes-256-cbc's in
2.40s
Doing aes-256-cbc for 3s on 8192 size blocks: 208581 aes-256-cbc's in
2.14s
OpenSSL 1.0.1e 11 Feb 2013
built on: Fri Mar 27 17:07:39 CET 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-256-cbc 78200.95k 239522.14k 507720.20k 700803.41k
798455.87k
I started to test this configuration and I have quickly realized that HW
offload is NOT used. After attaching to pid of the TOR daemon with perf I
have the following statistics:
Events: 205K cycles
47.56% libcrypto.so.1.0.0 [.] _sse_AES_encrypt_compact
6.32% libcrypto.so.1.0.0 [.] sha1_block_data_order
1.66% libcrypto.so.1.0.0 [.] AES_encrypt
1.42% libc-2.13.so [.] __memcpy_ia32
1.37% libcrypto.so.1.0.0 [.] CRYPTO_ctr128_encrypt
1.37% [ip_tables] [k] ipt_do_table
1.32% [kernel] [k] __do_softirq
1.17% [kernel] [k] sock_def_readable
0.77% libpadlock.so [.] padlock_aes_cipher
0.77% libc-2.13.so [.] _int_malloc
0.73% tor [.] tor_memeq
0.72% libssl.so.1.0.0 [.] ssl3_cbc_digest_record
0.62% [libata] [k] ata_scsi_queuecmd
0.57% [r8169] [k] 0x2719
0.55% [kernel] [k] __copy_to_user_ll
0.47% tor [.] siphash24
0.44% tor [.] __x86.get_pc_thunk.bx
0.41% [kernel] [k] nf_iterate
0.41% [vdso] [.] 0xb75209d1
0.39% tor [.] .L4
0.39% [kernel] [k] __copy_from_user_ll
0.38% libevent-2.0.so.5.1.7 [.] 0xae18
0.34% [nf_conntrack] [k] tcp_packet
0.33% [kernel] [k] skb_copy_bits
...
It looks like SSE implementation of AES is in use and looks like SHA1 is
NOT offloaded too.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15503>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list