DS112j hardware encryption engine

[Xennex]

Hoi,

Ik dacht altijd dat ik met mijn DS112j geen "hardware encryption engine" had maar nu blijkt dit verkeerd.

Maar mijn vraag is: merk ik er wel wat van?

Ik weet dat het een trage CPU is (1GHz) maar normale transfers zijn ca. 35MB/s upload en met encryptie is dat ca. 7MB/s maximaal.

Is dit normaal?

[Birdy]

DSM Help:

Waarom wordt de bestandsoverdracht trager wanneer de gedeelde map gecodeerd is?

Het is normaal dat gecodeerde gedeelde mappen langzamere bestandsoverdrachtsnelheden hebben. Codering kan de CPU-werklast aanzienlijk verhogen en de bestandsoverdrachtsnelheid verlagen.
Voor een verbeterde capaciteit kunt u de voorkeur geven aan een Synology NAS met een hardwarecoderingsengine:

Jouw DS heeft "Hardware Encryption Engine" dus, je kunt zeggen, je hebt wel een "verbeterde capaciteit" echter, denk dat de J-Versie, ondanks dat het geen CPU kracht kost, het wel zal merken, zoals je het al ondervindt.

[Xennex]

Jouw DS heeft "Hardware Encryption Engine" dus, je kunt zeggen, je hebt wel een "verbeterde capaciteit" echter, denk dat de J-Versie, ondanks dat het geen CPU kracht kost, het wel zal merken, zoals je het al ondervindt.

Hoe kan ik er überhaupt achter komen of die engine gebruikt wordt?

Heeft u enig idee welke instructies er dan voor gebruikt worden?

Zouden andere tools zoals gewone encryptieprogrammaatjes zoals "ccrypt" er ook baat bij hebben?

[Ben(V)]

Alle software die gebruikt maakt van AES encryption gebruikt die hardware, als die hardware er niet is worden de calls naar de encryption engine automatisch in software gedaan.
Voorbeelden zijn SSL, VPN en disk encryption.

Het is nauwelijk sneller dan de software variant en aangezien het altijd om het en/de crypten van streams gaat zal het nooit de performance beinvloeden, want de cpu is altijd vele malen sneller als die steams dus ook met software encryption.

Het enige echte voordeel is dat het niet te hacken is omdat het nu eenmaal in hardware zit.

Verder is het voornamelijk een intel marketing verhaal.

[Pippin]

De pdf van de SOC/CPU staat hier:
https://wikidevi.com/files/Marvell/88F6281.pdf

Mijn vermoeden is al heel lang dat de engine alleen aangesproken wordt voor encrypted backup.
Dit gebeurt zover ik weet middels OCF in kernel.

Hoe kan ik er überhaupt achter komen of die engine gebruikt wordt?

Op de CLI kun je met

Code: [Selecteer]

htop -d 20kijken wat er gebeurt. "-d 20" staat voor elke 2 seconden verversen.
Met F2 kun je kolommen e.d. aanpassen.

[Xennex]

Alle software die gebruikt maakt van AES encryption gebruikt die hardware, als die hardware er niet is worden de calls naar de encryption engine automatisch in software gedaan.

Welke instructie zou het zijn? Ik kan wel iets ...disassemblen om te zien of die calls er in staan.

Voorbeelden zijn SSL, VPN en disk encryption.

Maar disk encryption ... disk performance is veel sneller dan 7MB/s toch.

Het is nauwelijk sneller dan de software variant en aangezien het altijd om het en/de crypten van streams gaat zal het nooit de performance beinvloeden, want de cpu is altijd vele malen sneller als die steams dus ook met software encryption.

Ik bedoel op mijn NAS gebruikt SSH en VPN ook flink wat CPU.

Als ik encryptie uit zet op VPN is het processorgebruik een stukje lager (niet enorm).

Maar het maakte wel verschil, ik weet niet meer hoeveel.

Het was wel denk ik minstens 20% minder CPU door VPN.

(20% op wat het gebruikte).

Het enige echte voordeel is dat het niet te hacken is omdat het nu eenmaal in hardware zit.

Right.

Verder is het voornamelijk een intel marketing verhaal.

Maar dit is ARM. Hebben die dezelfde instructies?

Ik geloof je wel als je zegt dat het niet sneller is dan software.

[Xennex]

Mijn vermoeden is al heel lang dat de engine alleen aangesproken wordt voor encrypted backup.
Dit gebeurt zover ik weet middels OCF in kernel.

Dat klinkt wel erg goed:

At this point in time OCF-Linux provides acceleration for OpenSwan, OpenSSL, OpenSSH (scp, ssh, ...) and also supports the BSD crypto testing applications. It can accelerate DES, 3DES, AES, MD5, SHA, and Public Key operations and adds randomness to the kernels /dev/random by utilising the RNG hardware. This project is being actively developed as a high performance crypto solution for embedded devices but also applies equally well to any linux based server or desktop.

Dan kan ik er misschien wel achterkomen of dit gebruikt wordt...

Bijv. "ccrypt" moet ten eerste deze kernel interface gebruiken en daarna moet het worden aangesproken, maar misschien kan je wel informatie over het OCF-subsysteem opvragen...

Hetzelfde geldt voor eCryptFS (dat is natuurlijk het belangrijkste voor de Synology).

[Xennex]

http://www.marvell.com.cn/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf

Hier staat de ondersteunde hardware (pagina 175).

Er zijn 4 engines:

- md5
- des
- aes128
- aes128

Toen ik ooit LUKS aan het testen was was Blowfish (96 bit) een stuk sneller dan aes 128, wat vreemd zou zijn als aes 128 geaccelereerd zou worden... :-/.

Wel was het zo dat aes128 met 256 bit sleutels niet bijzonder langzamer was dan aes128 met 128 bit sleutels.

Dit is de encryptie module in the kernel:

/lib/modules/cesa_ocf_drv.ko

Hij is wel geladen dus dat zit in elk geval goed:

Code: [Selecteer]

$ lsmod | grep cesa
cesa_ocf_drv            7063  0
cesa_dev                1977  0
ocf                    17404  4 cryptosoft,ecryptfs,cesa_ocf_drv,cryptodev
Dus het lijkt vrij duidelijk dat het zou moeten werken.

Code: [Selecteer]

$ cat /proc/interrupts
           CPU0
  1:   52856176           -  kw_tick
 11:    5492715           -  mv_ethernet
 19:         27           -  ehci_hcd:usb1
 21:     200210           -  sata_mv

 22:     413145           -  cesa

 33:        172           -  serial
 34:         35           -  serial
Err:          0

[Xennex]

Dus zo te zien werkt dat gewoon.

Speculatieve post uit 2010:

https://www.spinics.net/lists/linux-crypto/msg27836.html

Dus ik denk dat ik me nergens om zorgen maak maar dat het gewoon niet zo snel is.

In elk geval als ik encryptie gebruik zal ik AES128 met 128, 192 of 256 bit keys moeten gebruiken.

Bedankt voor de antwoorden.

[Pippin]

Ik moet natuurlijk met het voorbeeld OpenVPN komen  , kijk eens naar mijn afbeelding.

OpenVPN maakt (standaard) gebruik van OpenSSL voor crypto taken. OpenSSL vanaf versie 1.0.0 zal AES-NI capabele hardware automatisch detecteren waardoor er, zoals het voorheen was, geen engine in de config aangegeven hoeft te worden. Een engine kan overigens ook acceleratie code in kernel zijn.

Dat het niet sneller is kan niet zo eenvoudig gesteld worden.
Op recente hardware die b.v. Intel AES-NI ondersteund, of het equivalent van andere merken, kan het wel degelijk uitmaken. Uit de afbeelding kun je ook opmaken dat het zo goed als altijd beter is OpenSSL`s ingebouwde instructies te gebruiken vanwege minder context switching. Dit geldt algemeen ook voor andere applicaties.


Op mijn N3150 bordje met Debian:

Met het volgende commando maakt OpenSSL geen gebruik van h.w. crypto support:
env OPENSSL_ia32cap=0 openssl speed -elapsed -evp aes-256-cbc -multi 8
evp              97659.74k   117140.11k   123383.16k   307494.50k   339199.79k

OpenSSL met h.w. crypto support:
openssl speed -elapsed -evp aes-256-cbc -multi 8
evp             618920.09k   882027.93k   1003271.00k  1041262.20k  1150214.31k

Het is echter nog heel wat gecompliceerder waardoor deze waarden niet 1-2-3 met elkaar vergelijkbaar zijn. Dat heeft te maken met het systeem waarop de test plaatsvindt, de configuratie, gebruikte ciphers/type encryptie, enz.

[Ben(V)]

https://en.wikipedia.org/wiki/AES_instruction_set

Alle huidige cpu's ondersteunen dit.
De ene in microcode, de andere met hardware en sommige geheel in software(extra drivers).

Het maakt allemaal niet veel verschil, zoals ik al zei.

Uiteraard heeft het niets te maken met het verschil in cpu gebruik bij het al of niet aanzetten van encryptie.
Je kunt nooit het verschil meten want op dat niveau kun je de hardware encryptie niet uitzetten en iets anders gebruiken.

[Pippin]

Het verschil in mijn voorbeeld wordt duidelijk doordat de resultaten, hierboven gepost, laten zien dat in dezelfde tijd meer crypto operaties plaatsvinden.

[Ben(V)]

Uiteraard is dat geen vergelijk.
Je vergelijkt appel met peren.

Zoals ik al zei het verschil tussen hardware en software encryptie zit in ofwel hardware in de cpu ofwel microcode die in de cpu zit, dat kun je toch niet gaan vergelijk met het niet gebruiken van de AES instructieset

Dan kun je het ook wel gaan vergelijken met het op de rekenmachine met de hand uitrekenen.

[Xennex]

Code: [Selecteer]

evp               6011.47k     6732.55k     6893.41k     6901.76k     6996.69k
Dat was het hardware commando.

For ARM there are two possible optimization levels:
  1. Without NEON
  2. With NEON (ARM7 only)

Boo?

Een post uit 2009 geeft aan dat OpenSSL "libcryptodev" nodig heeft, maar...

Code: [Selecteer]

$ OPENSSL_armcap=0 openssl speed -elapsed -evp aes-256-cbc -multi 8 -engine cryptodev
invalid engine "cryptodev"

23570:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:162:filename(/opt/lib/engines/libcryptodev.so): /opt/lib/engines/libcryptodev.so: cannot open shared object file: No such file or directory
Maar iemand zegt weer dat de engine al ingebakken zit:

libcryptodev.so? Why? It's builtin into openssl, you don't even need the
extra engines option, it's taken care of when building openssl with
cryptodev support in buildroot.

Als ik -evp weg haal:

Code: [Selecteer]

aes-256 cbc       6269.79k     6796.48k     6920.08k     6934.01k     7044.51k
Geen verschil eigenlijk.

Maar ik krijg geen debug output in /var/log/messages als ik:

Code: [Selecteer]

#  echo 1 > /sys/module/cryptosoft/parameters/swcr_debug
Maar meer nog denk ik niet dat openssl met cryptodev is gebouwd:

Code: [Selecteer]

options:  bn(64,32) md2(int) rc4(ptr,char) des(idx,cisc,16,long) idea(int) blowfish(ptr)

compiler: /home/slug/optware/cs08q1armel/toolchain/arm-2008q1/bin/arm-none-linux-gnueabi-gcc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O2 -pipe -I/home/slug/optware/cs08q1armel/staging/opt/include -DTERMIO -O3 -fomit-frame-pointer -Wall
Dit is echter wel in /opt...

Waaat, de inbgebouwde is nieuwer en beter:

Code: [Selecteer]

options:  bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) idea(int) blowfish(ptr)
compiler: /usr/local/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ccache-gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DOPENSSL_NO_ERR -I/usr/local/arm-none-linux-gnueabi/include -DSYNO_MARVELL_88F6281 -O2 -I/usr/syno/include -g -DSYNO_PLATFORM=MARVELL_88F6281 -DL_ENDIAN -DTERMIO -Os -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/syno/fips//include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
Euhm, okay:

Code: [Selecteer]

evp               4836.78k     5710.98k     5976.59k     6037.56k     6093.40k
Dat is langzamer dan hiervoor...

Maar zonder de -evp (Ik weet niet of dat nuttig is):

Code: [Selecteer]

aes-256 cbc       9057.94k    10289.41k    10681.31k    10724.04k    10923.55k

[Xennex]

Zoals ik al zei het verschil tussen hardware en software encryptie zit in ofwel hardware in de cpu ofwel microcode die in de cpu zit, dat kun je toch niet gaan vergelijk met het niet gebruiken van de AES instructieset

Ben ik weet eerlijk gezegd niet waar je het over hebt.

Maar summary van mij:

- /opt OpenSSL gebruik van -evp vlag maakt niks uit en laatste getal:  7000k

- /usr/syno/bin OpenSSL: met -evp langzamer at 6000k en zonder -evp sneller at 10000k.

Ik weet dus niet wat OpenVPN gebruikt.

Maar dat is de Synology versie:

Code: [Selecteer]

$ ldd /usr/sbin/openvpn
        libssl.so.1.0.0 => /lib/libssl.so.1.0.0 (0x40026000)
Terwijl SSHD weer de /opt versie gebruikt:

Code: [Selecteer]

$ ldd /opt/sbin/sshd
        libcrypto.so.0.9.8 => /opt/lib/libcrypto.so.0.9.8 (0x40026000)
Buuu.