EEVblog® Electronics Community Forum
Products => Computers => Programming => Topic started by: DiTBho on February 10, 2023, 02:26:44 pm
-
Cryptographic operations can be very expensive when performed in software, but - in theory - they can be performed by a Cryptographic hardware accelerator to improve performance.
So, I like the idea behind Crypto Co-ops because, at least, they help with { AES-128, AES-256 }, { SHA-1, SHA-256, SHA-512 } ciphers to perform symmetric key encryption and calculate message digests in hardware.
Love that, but it's all a new kind of experience for me.
I'd like to play with GNU/Linux. OpenSSH, VPN, IPsec, ... That stuff.
First I have to understand
- the kernel overhead to "pass" data from the userspace to the hardware accelerator.
- which applications can really benefit commercial hardware accelerators (there are just a few miniPCI modules).
-
What kind of CPU are you using? On x86's the AES instructions just use the CPU state and there is no need to leave user space, and no overhead.
Also, you may look into Bernstein's ciphers (Chacha etc.) that were specifically designed to be very fast without the need for accelerators.
If I was the NSA, I would talk Intel into adding some gates to the CPU to record a random sampling of keys (or an average?) in some hidden flash cells when those special key scheduling instructions are used, of course dropping 50-60 bits or so of entropy to make sure that you still need beefy hardware.
-
What kind of CPU are you using?
miniPCI crypto Co-op -> { MIPS32R2BE@800Mhz, MIPS32R2LE@400Mhz }
PCI32 crypto Co-op -> { PPC405@400Mhz, PPC7450@1600Mhz, PA8900@1100Mhz, MIPS4-R14000@600Mhz }
None of them has Crypto-instructions :o :o :o
-
It all depends on how the kernel driver is implemented.
For example for a general write() call, normally the driver will first check that the memory segment provided to the call is indeed readable by the calling process. It will then copy the data from the user space into a kernel-allocated page or maybe an internal buffer, and then later program the card's DMA to fetch memory from that page. The driver has to make arrangements so that the data will end up in physical RAM before the card attempts to fetch it. Depending on the CPU, this may be trivial to ugly and nasty.
If the card doesn't support DMA, it might expose a buffer in PCI address space, or maybe even a simple register for FIFO operation. In that case things can get quite slow and inefficient.
The kernel driver could support mmap(), in which case the hardware could DMA into pages that will be directly provided to the process without the CPU having to do any coping, however that depends on the kernel driver, and you can have a mmap() interface filled by software.
Last time I wrote a kernel driver was maybe 7 years ago and it was on Spartan/Microblaze and Zynq. I didn't follow things closely since, but I've heard there are new things such as io_uring.
The read() call is the same thing but in reverse order.
Hope this helps.
-
is there a crypto accelerator, commodities such as copper and coffee, that implements "blowfish" or "twofish"? :-//
-
https://www.researchgate.net/publication/327194185_Hardware-Accelerated_Twofish_Core_for_FPGA (https://www.researchgate.net/publication/327194185_Hardware-Accelerated_Twofish_Core_for_FPGA)
-
- the kernel overhead to "pass" data from the userspace to the hardware accelerator.
If DMA is available, the total CPU overhead is about the same as copying the data from one process to another using a socket pair, say an Unix domain datagram socket. There is a bit of setup work when setting the IV etc. depending on the algorithm but it is within the noise. Without DMA, about 1.5 to 2.0x that. So not too much, really.
There are two ways such an accelerator can be used from userspace:- AF_ALG sockets, see man 2 socket (https://man7.org/linux/man-pages/man2/socket.2.html) and kernel crypto userspace interface (https://www.kernel.org/doc/html/latest/crypto/userspace-if.html). Linux-specific.
- /dev/crypto (http://cryptodev-linux.org/) character device, via a dedicated (out-of-tree but open source) kernel module, used by e.g. OpenWRT. Compatible with BSD /dev/crypto interface.
While the latter may gives better performance (http://cryptodev-linux.org/comparison.html) and is compatible with BSD /dev/crypto device, an application needs access to the crypto character device to use it.
The former is available to all processes as a special socket() family, so is easier to use, but is also Linux-only (AFAIK).
- which applications can really benefit commercial hardware accelerators (there are just a few miniPCI modules).
Anything that uses TLS (or SSL), as long as your OpenSSL/GnuTLS was compiled with either or both of the above hardware crypto support.
In Linux userspace, that means basically anything that uses cryptography, will use the hardware accelerator. Using /dev/crypto, you can set the access permissions so that only specific users and/or groups can access the hardware accelerator, and everything else will use software crypto. I haven't checked, but I think both OpenSSL and GnuTLS have tunables for selecting which kinds of crypto work will be delegated to the accelerator, too.
-
Thanks.
Talking about kernels, is there good support in
v2.6.* family? (ok, too old, so I am thinking about the last ones, v2.6.35.. v2.6.39)
v4.* family?
rather than kernel v5.* and v6.* family?
-
Talking about kernels, is there good support in
v2.6.* family? (ok, too old, so I am thinking about the last ones, v2.6.35.. v2.6.39)
v4.* family?
AF_ALG was added in 2.6.38, and the speed comparison (http://cryptodev-linux.org/comparison.html) was done on a 3.0.0 kernel. As long as your crypto accelerator has a Linux kernel driver, cryptodev (/dev/crypto) can be used to expose it to userspace, I believe even in 2.6.x kernels. Cryptodev really just provides userspace access to the kernel-internal crypto API.
-
# ./output/aes
Got cbc(aes) with driver cbc-aes-hifn0
Got cbc(aes) with driver cbc-aes-hifn0
AES Test passed
cryptodev: added
aes-hw: test-passed!
we have hw acceleration ;D
-
How does it compare to just SW solution on the same host CPU?
-
How does it compare to just SW solution on the same host CPU?
comparing CPU-crypto vs COP-acceleration on scp file transfer (massively uses OpenSSL)
PCI crypto module on 133Mhz PowerPC40x CPU: 5x speedup
miniPCI crypto module on 400Mhz MIPS32 CPU: 3x speedup
PCI crypto module on 1.4Ghz PowerPC7450 CPU: 0.80x speedup (slower)
PCI crypto module on 1.1Ghz HP-PA8900 CPU: 0.70x speedup (slower, the PCI on HPPA has a lot of problems)
-
For an experiment, I need this file
openssh-5.4p1-hpn13v7-x509variant.diff.gz
but I cannot find it :-//
There is something here (https://roumenpetrov.info/openssh/download-20110204.html), but not the file I need.
-
ok, now I want this (https://shop.netgate.com/products/netgate-cpic-8955-cryptographic-accelerator-card-with-qat) card, or even better, this (https://shop.netgate.com/products/netgate-cpic-8955-cryptographic-accelerator-card-with-qat) one :D :D :D
-
so, after weeks of struggle with tons of bugs (even two terrible ones lurking around in the last kernel 6.2.0), now the crypto module is somehow working with ad-hoc applications I have written to use DES
# mycrypto_test
AES hw acceleration test
using /dev/cryptodev ...
got cbc(aes) with driver cbc-aes-cryptodev ... supported
Test: passed
unfortunately all the OpenSSH clients served by /usr/sbin/sshd (OpenSSH server) are not happy
cryptodev: ssh[20569] (cryptodev_cipher_init:135): Failed to load cipher cbc(blowfish)
cryptodev: ssh[20569] (crypto_create_session:257): Failed to load cipher for cbc(blowfish)
cryptodev: ssh[20569] (crypto_create_session:170): bad cipher: 4
cryptodev: ssh[20569] (cryptodev_hash_init:339): Failed to load transform for hmac(md5)
cryptodev: ssh[20569] (crypto_create_session:280): Failed to load hash for hmac(md5)
cryptodev: ssh[20569] (cryptodev_hash_init:339): Failed to load transform for hmac(sha1)
cryptodev: ssh[20569] (crypto_create_session:280): Failed to load hash for hmac(sha1)
cryptodev: ssh[20569] (cryptodev_hash_init:339): Failed to load transform for hmac(rmd160)
cryptodev: ssh[20569] (crypto_create_session:280): Failed to load hash for hmac(rmd160)
cryptodev: ssh[20569] (cryptodev_hash_init:339): Failed to load transform for md5
cryptodev: ssh[20569] (crypto_create_session:280): Failed to load hash for md5
cryptodev: ssh[20569] (cryptodev_hash_init:339): Failed to load transform for sha1
cryptodev: ssh[20569] (crypto_create_session:280): Failed to load hash for sha1
They would like to have services for which there is no hardware acceleration, and cryptodev complains on its corner
- blowfish
- hmac(md5)
- hmac(sha1) <----------- there is support for "sha" != "sha1"
- hmac(rmd160)
:-//
-
Also don't forget about carryless multiplication instructions like PMULL, PCLMULQDQ, etc. that are used for GHASH and Polyval. I'm not sure if they're more or less common than AES-NI though.
-
Also don't forget about carryless multiplication instructions like PMULL, PCLMULQDQ, etc. that are used for GHASH and Polyval. I'm not sure if they're more or less common than AES-NI though.
Yup, I think they are supported in modern crypto-CPU-extensions :o