Hardware Cryptography with GNU/Linux: anyone? - Page 1
Forum section: electronics / general

author: DiTBho
author_rank: Super Contributor
timestamp: February 10, 2023, 02:26:44 pm
content: 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).

author: berke
author_rank: Frequent Contributor
timestamp: February 10, 2023, 06:21:31 pm
content: 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.

author: DiTBho
author_rank: Super Contributor
timestamp: February 10, 2023, 06:58:53 pm
content: Quote from: berke on February 10, 2023, 06:21:31 pmminiPCI 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

author: berke
author_rank: Frequent Contributor
timestamp: February 10, 2023, 10:44:07 pm
content: 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 hardwarecouldDMA 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.

author: DiTBho
author_rank: Super Contributor
timestamp: February 13, 2023, 08:47:35 pm
content: is there a crypto accelerator, commodities such as copper and coffee, that implements "blowfish" or "twofish"?

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 13, 2023, 10:14:54 pm
content: https://www.researchgate.net/publication/327194185_Hardware-Accelerated_Twofish_Core_for_FPGA

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 15, 2023, 12:48:54 am
content: Quote from: DiTBho on February 10, 2023, 02:26:44 pmIf 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, seeman 2 socketandkernel crypto userspace interface. Linux-specific./dev/cryptocharacter 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 maygives better performanceand 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 specialsocket()family, so is easier to use, but is also Linux-only (AFAIK).Quote from: DiTBho on February 10, 2023, 02:26:44 pmAnything 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.

author: DiTBho
author_rank: Super Contributor
timestamp: February 15, 2023, 08:07:55 am
content: Thanks.Talking about kernels, is there good support inv2.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?

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 15, 2023, 09:45:13 am
content: Quote from: DiTBho on February 15, 2023, 08:07:55 amAF_ALG was added in 2.6.38, and the speedcomparisonwas 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.

author: DiTBho
author_rank: Super Contributor
timestamp: March 08, 2023, 02:53:28 pm
content: Code:# ./output/aesGot cbc(aes) with driver cbc-aes-hifn0Got cbc(aes) with driver cbc-aes-hifn0AES Test passedcryptodev: addedaes-hw: test-passed!we have hw acceleration

author: Gribo
author_rank: Frequent Contributor
timestamp: March 09, 2023, 05:28:31 pm
content: How does it compare to just SW solution on the same host CPU?

author: DiTBho
author_rank: Super Contributor
timestamp: March 09, 2023, 06:18:19 pm
content: Quote from: Gribo on March 09, 2023, 05:28:31 pmcomparing CPU-crypto vs COP-acceleration on scp file transfer (massively uses OpenSSL)PCI crypto module on 133Mhz PowerPC40x CPU: 5x speedupminiPCI crypto module on 400Mhz MIPS32 CPU: 3x speedupPCI 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)

author: DiTBho
author_rank: Super Contributor
timestamp: March 09, 2023, 08:46:05 pm
content: For an experiment, I need this fileopenssh-5.4p1-hpn13v7-x509variant.diff.gzbut I cannot find itThere is somethinghere, but not the file I need.

author: DiTBho
author_rank: Super Contributor
timestamp: March 12, 2023, 11:16:34 pm
content: ok, now I wantthiscard, or even better,thisone

author: DiTBho
author_rank: Super Contributor
timestamp: March 17, 2023, 10:33:59 am
content: 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 DESCode:# mycrypto_testAES hw acceleration testusing /dev/cryptodev ...got cbc(aes) with driver cbc-aes-cryptodev ... supportedTest: passedunfortunately all the OpenSSH clients served by /usr/sbin/sshd (OpenSSH server) are not happyCode:cryptodev: ssh (cryptodev_cipher_init:135): Failed to load cipher cbc(blowfish)cryptodev: ssh (crypto_create_session:257): Failed to load cipher for cbc(blowfish)cryptodev: ssh (crypto_create_session:170): bad cipher: 4cryptodev: ssh (cryptodev_hash_init:339): Failed to load transform for hmac(md5)cryptodev: ssh (crypto_create_session:280): Failed to load hash for hmac(md5)cryptodev: ssh (cryptodev_hash_init:339): Failed to load transform for hmac(sha1)cryptodev: ssh (crypto_create_session:280): Failed to load hash for hmac(sha1)cryptodev: ssh (cryptodev_hash_init:339): Failed to load transform for hmac(rmd160)cryptodev: ssh (crypto_create_session:280): Failed to load hash for hmac(rmd160)cryptodev: ssh (cryptodev_hash_init:339): Failed to load transform for md5cryptodev: ssh (crypto_create_session:280): Failed to load hash for md5cryptodev: ssh (cryptodev_hash_init:339): Failed to load transform for sha1cryptodev: ssh (crypto_create_session:280): Failed to load hash for sha1They would like to have services for which there is no hardware acceleration, and cryptodev complains on its cornerblowfishhmac(md5)hmac(sha1) <----------- there is support for "sha" != "sha1"hmac(rmd160)

author: elagergren
author_rank: Unknown
timestamp: March 17, 2023, 09:05:19 pm
content: 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.

author: DiTBho
author_rank: Super Contributor
timestamp: March 17, 2023, 09:11:43 pm
content: Quote from: elagergren on March 17, 2023, 09:05:19 pmYup, I think they are supported in modern crypto-CPU-extensions