I had this problem before and I forgot the solution
Using OpenVPN with OpenSSL and the Cryptodev engine always fails the OpenVPN crypto test at byte 560 with a RAND_bytes() fail assertion. This is regardless of any hardware crypto driver loaded.
I had this working before I did full clean install of the build environment so it must be some selection I missed.
select the hardware acceleration in the OpenSSL lib.
have some (p)rng show up under /proc/crypto
check dmesg log that the CRNG is initialized.
Low entropy could be a reason, but if I run the test again immediately it runs until the same 560. I have the same problem on different SoC / builds so it must be a selection / module I’m missing.
I found the problem.
The OpenVPN --test-crypto test runs fine as long as I don't select Use Hardware / Accelerated Digests.
This doesn't make a lot of sense (glancing over both the cryptodev and openssl code). Both are not (p)rng related?? For now I keep Hardware Digest enabled to do benchmarking using Openssl-utils.
There is an issue with some devices with a proposed PR, but things appear fine with
Thanks for pointing me at those pull requests. However this problem doesnt seem to be device specific. Without any hardware driver loaded it generates the same problem.
I will try again upgrading to the OpenSSL 1.1.1 version (we are still using 1.0.1). There are some patches already but it didn’t seem to make a big difference a few months ago when we did some testing. Admittedly Cipher tests only, no digests which is what I’m trying to implement now.
I did a quick modification to my code to see what is being called. It seems that during every cycle of the OpenVPN --test-crypto it is somehow calling SHA1. This seems be be OpenSSL related, but its strange that the cryptodev doesn't fallback to software-only as it does with ciphers.
Needs more investigation.
It's OpenSSL related, as cryptodev stated in README..
This file has been truncated.
This is a /dev/crypto device driver, equivalent to those in OpenBSD or
FreeBSD. The main idea is to access of existing ciphers in kernel space
from userspace, thus enabling the re-use of a hardware implementation of a
For questions and suggestions please use the mailing lists at:
=== How to combine with cryptographic libraries ===
GnuTLS needs to be compiled with --enable-cryptodev in order to take
advantage of /dev/crypto. GnuTLS 3.0.14 or later is recommended.
Note that OpenSSL's cryptodev implementation is outdated, and there
are issues with it. For that we recommend to use the patches
I am aware of these warnings, however they are also very old (and likely outdated as well).
The problem is/was that I was trying to use hardware digests. I never used (or enabled) them. Without this, cryptodev will only be used for ciphers.
I'm not sure why the cryptodev implementation doesn't fallback to software digests like it does for ciphers.