With peer verification disabled (`-d`), the same client completes a full TLS
session over AF_ALG and gets application data back:

$ ./examples/client/client -h www.google.com -g -d -p 443
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
SSL connect ok, sending GET...
HTTP/1.0 200 OK

I built the examples (`--enable-examples`) and ran your command directly, no curl involved:

$ ./examples/client/client -h www.google.com -g -A ./certs/external/ca-google-root.pem -p 443
CRL callback url = http://crl.pki.goog/gsr1/gsr1.crl
wolfSSL_connect error -362, CRL missing, not loaded

Adding `-C` to disable curl gives the same -155 as curl:

$ ./examples/client/client -h www.google.com -g -A ./certs/external/ca-google-root.pem -C -p 443
wolfSSL_connect error -155, ASN sig error, confirm failure

Same result whether `-A` is the single Google root or my full system CA bundle.
So the bundled client reproduces -155 — curl is not involved.

1. Disabling atmel-sha (and atmel-aes) at the kernel level

The atmel-sha crypto driver is built in, so there's no module to `rmmod`, but we can unbound it via sysfs.

# sha256 providers by priority -- atmel-sha256 (hardware) wins at 300
$ grep -A4 '^name *: sha256$' /proc/crypto | grep -E 'driver|priority'
driver       : atmel-sha256
priority     : 300
driver       : sha256-neon
priority     : 250
driver       : sha256-asm
priority     : 150
driver       : sha256-generic
priority     : 100


# Unbind atmel-sha -> sha256-neon (software) becomes the active provider
$ echo f0028000.crypto > /sys/bus/platform/drivers/atmel_sha/unbind
$ grep -A4 '^name *: sha256$' /proc/crypto | grep -E 'driver|priority' | head -2
driver       : sha256-neon
priority     : 250


$ curl -v https://www.google.com
* SSL_connect failed with error -155: ASN sig error, confirm failure
curl: (35) SSL_connect failed with error -155: ASN sig error, confirm failure

The -155 persists with software SHA256. I then also unbound the AES engine:

$ echo f002c000.crypto > /sys/bus/platform/drivers/atmel_aes/unbind
$ curl -v https://www.google.com
curl: (35) SSL_connect failed with error -155: ASN sig error, confirm failure

Still -155 with both SHA and AES in software. So the failure is independent of the Atmel hardware drivers.

The testwolfcrypt shows SHA256 operations as passing. Is there something like `rmod atmel-sha` available to temporarily disable the atmel-sha crypto driver and fall back to software at the kernel level? This would help narrow it down to an issue in wolfSSL af_alg calls potentially with buffer alignment or a driver issue.

Also could you try the bundled wolfssl client example to rule out possible complications arising from cURL + wolfSSL?

./examples/client/client -h www.google.com -g -A ./certs/external/ca-google-root.pem  -p 443

Results of testwolfcrypt below:

$ testwolfcrypt 
Math:     Multi-Precision: Wolf(SP) word-size=32 bits=3072 sp_int.c
------------------------------------------------------------------------------
 wolfSSL version 5.8.4
------------------------------------------------------------------------------
macro    test passed!
error    test passed!
MEMORY   test passed!
base64   test passed!
base16   test passed!
asn      test passed!
MD4      test passed!
SHA      test passed!
SHA-256  test passed!
SHA-384  test passed!
SHA-512  test passed!
SHA-512/224  test passed!
SHA-512/256  test passed!
RANDOM   test passed!
Hash     test passed!
HMAC-SHA test passed!
HMAC-SHA256 test passed!
HMAC-SHA384 test passed!
HMAC-SHA512 test passed!
HMAC-KDF    test passed!
SSH-KDF     test passed!
PRF         test passed!
TLSv1.2 KDF test passed!
TLSv1.3 KDF test passed!
GMAC     test failed!
 error L=17481
 [fiducial line numbers: 10443 30112 49891 62840]
Exiting main with return code: -1

In regards to WOLFSSL_AFALG_HASH, I modified the buildroot makefile to try and undefine it via CFLAGS

WOLFSSL_CONF_ENV += CFLAGS="$(TARGET_CFLAGS) -UWOLFSSL_AFALG_HASH"

Thanks for you help.

Could you run ./wolfcrypt/test/testwolfcrypt to confirm if SHA256 hash operations are successful?

How did you test without WOLFSSL_AFALG_HASH, if building with ./configure was configure.ac altered and then ./configure regenerated?

wolfSSL,
Jacob

I'm trying to use wolfSSL with AF_ALG on an ARM32 platform (Microchip SAMA5D2, Cortex-A5) to get hardware-accelerated AES-GCM for TLS. The goal is to offload bulk encryption to hardware while keeping certificate verification in software.

When I enable `--enable-afalg`, all certificate verification fails with error -155 (`ASN_SIG_CONFIRM_E`)

What we have:
- wolfSSL 5.8.4 (also tested 5.7.2)
- libcurl 8.18.0
- Linux with musl libc (Buildroot)
- hardware: Atmel AES via AF_ALG (`atmel-gcm-aes` driver)

Platform details:
- Microchip SAMA5D2 (ARM Cortex-A5)
- Linux 6.x, musl libc, Buildroot

Configure (minimal reproduction):

./configure --enable-curl --enable-afalg

What happens

$ curl https://www.google.com
SSL_connect failed with error -155: ASN sig error, confirm failure

This affects every HTTPS site

Hardware AES is working if we skip the certificate verification

$ grep -i aes /proc/interrupts
157:          3  atmel-aic5   9 Level     atmel-aes

$ curl -k https://www.google.com   # skip verification
(succeeds, returns HTTP 200)

$ grep -i aes /proc/interrupts
157:         57  atmel-aic5   9 Level     atmel-aes

The AES interrupt count jumped from 3 to 57 during that connection. So AF_ALG AES-GCM is working for data encryption. It's only the certificate verification that breaks.

What I've tried (all fail with -155):
- Minimal config: just `--enable-curl --enable-afalg`
- wolfSSL 5.7.2 and 5.8.4
- SP math (default on ARM) vs TFM (`--enable-fastmath`)
- With and without `WOLFSSL_AFALG_HASH`
- libcurl 8.15.0 and 8.18.0

What works:
- `--enable-all` without `--enable-afalg` - certificates verify fine
- `--enable-curl` without `--enable-afalg` - certificates verify fine
- Basically anything WITHOUT `--enable-afalg`

Questions:
1. Has anyone successfully used `--enable-afalg` on ARM32 with certificate verification?
2. Is there a known issue with AF_ALG + curl on ARM?
3. Any suggestions for debugging this further?

I am keen to get hardware AES working since as we are pushing the boundaries of the CPU for our application.

Thanks for any help.