!!WARNING!!
!!EXPERIMENTAL!! This is not a drill. Using these codes/binaries/instructions may result DATA LOSS/DATA CORRUPTION/BRICK DEVICE/SECURITY VULNERABLE etc. USE AT YOUR OWN RISK
This article is not for beginner. You must understand what you are doing.
Skip to the the bottom if you just want the pre-compiled cryptodev binaries for bodhi's 5.2.9 Kirkwood kernel/debian buster.
Marvell CESA support these "usable" offload cipher/digest:
AES128-CBC/AES192-CBC/AES256-CBC
SHA1/SHA256
In debian 10 we have 2 ways to utilize HW Crypto on userland program.
AF_ALG
Install: You can enable AF_ALG by editing the /etc/ssl/openssl.cnf. Make sure you have something like these in the configuration:
Known issue:
You may notice the openssh isn't providing either of those cipher by default...And when you explicit setting it. Boom(I did warned you). Check debian bug#931272 for details.
In short. We need to rebuild openssh without seccomp support(seccomp isn't enforced by default until debian buster. But again these procedure weaken the security a bit)
Just keep in mind this will prevent you from receiving openssh security updates. You have to rebuild on every release for the security.
Or...you could just disable the offload cipher for openssh(default).
cryptodev
It's the most unreliable and yet most speed solution amount these two. If anything there that most are likely to corrupt your data. This is it. Additional modules are required, both kernel and openssl.
Kernel: You have to use the latest source from their github or it won't work on 5.x kernel. And so far it's not compiled on bodhi's headers files for some reason.
I just cross-compiled it. The kernel module binary is on attachment. (cryptodev.zip )
OpenSSL: Until recently you still have to re-compile the whole openssl for the cryptodev support(now called devcrypto). To make matter worse after you done that it become a builtin-engine. YOU COULD NOT DISABLE a builtin-engine unless unload the kernel module. Not even mention it could break your openssh almost entirely...
But luckily openssl source tree has just made it become a module instead a builtin-engine. Some bugs were also fixed(no longer breaking openssh as long as you not using the offloaded cipher). So I backport the module to the buster's openssl1.1.1. which is available in attachment
There are two version of it. devcrypto-with-hash has the offload digest(md5/sha) support, which is straight from official source. devcrypto-wo-hash does not as I strip the digest codes.
Depends on the scenario. Offload digest has the advantage on hashing big files, however its calling overhead is so big it's not suitable for any SSL/TLS application(benchmark #2). You can choose either of them.
Install: Extract and put the "devcrypto.so" directly into "/usr/lib/arm-linux-gnueabi/engines-1.1"
Verify: run "openssl engine devcrypto". If you see:
Enable procedure is same as af_alg. Just replace "afalg" with "devcrypto".
Known issue:
It will break openssh connection if you enable this engine with offloaded cipher(i.e. aes128-cbc) setting in sshd_config(which is not default). Unlike af_alg I didn't find any workaround.
Wanna use both? No problem
Openssl support "OPENSSL_CONF" as environment var. You can make another openssl.cnf with different engine. Then pass the file path to the executable with OPENSSL_CONF. For example:
Q&A:
Q. Why there are so many useless blahblah. I just want more specific commands
A. It's not for the beginner and it's EXPERIMENTAL.
Q. My ssh is not working anymore.
A. Remove the configuration and modules.
Q. My encrypted data corrupted.
A. You have been warned.
Special thanks to https://wiki.kobol.io/cesa/ and bodhi
!!EXPERIMENTAL!! This is not a drill. Using these codes/binaries/instructions may result DATA LOSS/DATA CORRUPTION/BRICK DEVICE/SECURITY VULNERABLE etc. USE AT YOUR OWN RISK
This article is not for beginner. You must understand what you are doing.
Skip to the the bottom if you just want the pre-compiled cryptodev binaries for bodhi's 5.2.9 Kirkwood kernel/debian buster.
Marvell CESA support these "usable" offload cipher/digest:
AES128-CBC/AES192-CBC/AES256-CBC
SHA1/SHA256
In debian 10 we have 2 ways to utilize HW Crypto on userland program.
- AF_ALG
Pro: Builtin by debian buster. Somewhat more compatible/reliable than cryptodev.
Con: Inefficiency.
Have compatibility issue with latest openssh on debian buster(we will cover that).
- cryptodev
Pro: Efficiency. Much lower overhead means MUCH MORE THROUGHPUT and more precious CPU cycles available for other usage. Zero copy is real.
Con: Additional module required.
Have compatibility issue with openssh too(WTH openssh?)
AF_ALG
Install: You can enable AF_ALG by editing the /etc/ssl/openssl.cnf. Make sure you have something like these in the configuration:
openssl_conf = default_conf [default_conf] ssl_conf = ssl_sect engines = afalg_sect [afalg_sect] afalg = afalg_engine_on [afalg_engine_on] default_algorithms = ALL init = 1Verify: "openssl engine". If you see
(dynamic) Dynamic engine loading support (afalg) AFALG engine supportthen it's working. And you have to use either AES128-CBC/AES192-CBC/AES256-CBC in the specific program's cipher setting. I'm not going to cover those setting.
Quote
BTW I'm not a cryptography expert but as far as I know CBC mode is still "acceptable safe" to date as long as you have all the security patch and TLS ver ≥1.1. This is certainly not the most secure mode anymore and it may become unsafe in the future. You have been warned
Known issue:
You may notice the openssh isn't providing either of those cipher by default...And when you explicit setting it. Boom(I did warned you). Check debian bug#931272 for details.
In short. We need to rebuild openssh without seccomp support(seccomp isn't enforced by default until debian buster. But again these procedure weaken the security a bit)
apt source openssh cd openssh-x.x.x # Edit debian/rules and add it to common build options: confflags += --with-sandbox=no dpkg-buildpackage -b -us # After finished. Install the debs and job doneYou can freeze the openssh version by "apt-mark hold" to avoid accidently update your openssh.
Just keep in mind this will prevent you from receiving openssh security updates. You have to rebuild on every release for the security.
Or...you could just disable the offload cipher for openssh(default).
cryptodev
It's the most unreliable and yet most speed solution amount these two. If anything there that most are likely to corrupt your data. This is it. Additional modules are required, both kernel and openssl.
Kernel: You have to use the latest source from their github or it won't work on 5.x kernel. And so far it's not compiled on bodhi's headers files for some reason.
I just cross-compiled it. The kernel module binary is on attachment. (cryptodev.zip )
OpenSSL: Until recently you still have to re-compile the whole openssl for the cryptodev support(now called devcrypto). To make matter worse after you done that it become a builtin-engine. YOU COULD NOT DISABLE a builtin-engine unless unload the kernel module. Not even mention it could break your openssh almost entirely...
But luckily openssl source tree has just made it become a module instead a builtin-engine. Some bugs were also fixed(no longer breaking openssh as long as you not using the offloaded cipher). So I backport the module to the buster's openssl1.1.1. which is available in attachment
There are two version of it. devcrypto-with-hash has the offload digest(md5/sha) support, which is straight from official source. devcrypto-wo-hash does not as I strip the digest codes.
Depends on the scenario. Offload digest has the advantage on hashing big files, however its calling overhead is so big it's not suitable for any SSL/TLS application(benchmark #2). You can choose either of them.
Install: Extract and put the "devcrypto.so" directly into "/usr/lib/arm-linux-gnueabi/engines-1.1"
Verify: run "openssl engine devcrypto". If you see:
(devcrypto) /dev/crypto enginethen it's working.
Enable procedure is same as af_alg. Just replace "afalg" with "devcrypto".
Known issue:
It will break openssh connection if you enable this engine with offloaded cipher(i.e. aes128-cbc) setting in sshd_config(which is not default). Unlike af_alg I didn't find any workaround.
Wanna use both? No problem
Openssl support "OPENSSL_CONF" as environment var. You can make another openssl.cnf with different engine. Then pass the file path to the executable with OPENSSL_CONF. For example:
OPENSSL_CONF=/path/to/engine/afalg.cnf sshd
Q&A:
Q. Why there are so many useless blahblah. I just want more specific commands
A. It's not for the beginner and it's EXPERIMENTAL.
Q. My ssh is not working anymore.
A. Remove the configuration and modules.
Q. My encrypted data corrupted.
A. You have been warned.
Special thanks to https://wiki.kobol.io/cesa/ and bodhi