wolfSSL - Embedded SSL Library — wolfSSL

chunk size in datastream

null@example.com (BerHav) — Tue, 18 Aug 2026 18:42:00 +0000

Hi there,

In a server response, the data is transmitted in separate chunks. When processing these data chunks, the size of the next chunk appears interspersed with the data itself. Is this expected behavior? Is there a setting to hide this within the data stream? The application is developed in the Arduino IDE for STM32 using a W5500 Ethernet interface and utilizes wolfSSL 5.8.4.

The 0x1b70 is the size of the next chunk.

The data is read into 256-byte buffers. This part works correctly, but the chunk size appearing in the middle of the stream makes interpretation difficult.

We hope that wolfSSL will support msquic.

null@example.com (cainiao) — Sat, 25 Jul 2026 09:34:44 +0000

wolfSSL does not currently support msquic. Are there any means to enable support for msquic in wolfSSL?

Using wolfSSL library in C

null@example.com (feynhat) — Mon, 13 Jul 2026 18:06:42 +0000

Hello. I am new to wolfssl.

I compiled the latest versions of wolfssl and wolfCLU, on two systems - my laptop running archlinux and a raspberry pi running raspbian (a debian-based distro), and ran ldconfig on both of them.

On my pi the wolfssl library runs as expected. I run the example server code given here https://www.wolfssl.com/docs/quickstart/ and compile it using

gcc server.c -lwolfssl -o server

and run server. It gives me

 listening on port 11111

as expected.

But if I run it on my archlinux laptop, I get,

./server: error while loading shared libraries: libwolfssl.so.45: cannot open shared object file: No such file or directory

I guess this is happening because the compiled program looks for libraries in /usr/lib but libwolfssl.so.45 gets installed in /usr/local/lib. So one easy fix is to create a symbolic link in /usr/lib that points to /usr/local/lib/libwolfssl.so.45. Another fix would be to provide the correct install prefix /usr/lib while building wolfssl (I haven't tried this though).

My question is not about how to fix this or how to get `server` to run, but rather why is this happening. I am trying to understand the compilation process for programs that use wolfssl. What is different on my laptop from my pi that is making this happen? The libwolfssl.so.45 is in /usr/local/lib in both cases.

Here is the output of gcc -v on both my machines, if that helps:

On laptop:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/16/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust,cobol --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues --with-build-config=bootstrap-lto --with-gcc-major-version-only --with-linker-hash-style=gnu --with-system-zlib --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-fixincludes --disable-libssp --disable-libstdcxx-pch --disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.1.1 20260625 (GCC)

and on pi:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/12/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14+deb12u1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14+deb12u1)

The environment variable $LD_LIBRARY_PATH is not set in both cases.

wolfSSL with wolfIP

null@example.com (ah346743) — Thu, 11 Jun 2026 12:11:55 +0000

I'm experimenting with using wolfSSL and wolfIP. When calling wolfSSL_connect() I get a failure with the log message "Your IO Send callback is null, please set".

I can see this is something to do with wolfSSL_SetIOWriteCTX(), but I'm not entirely sure what value to use - I'm a novice with wolfSSL.

Are there specific values I should set to link the two components together?

Hybrid TLS 1.3 (PQC) support in wolfSSL JNI (Java)

null@example.com (Pro_Orq) — Tue, 21 Apr 2026 16:20:34 +0000

Hello,

I’ve been reviewing the wolfSSL documentation and have tested the hybrid TLS 1.3 examples in C. On the native side, I was able to successfully compile wolfSSL with PQC_Hybrids and run the client/server examples using hybrid TLS 1.3 without any issues.

I’m new to this area, and I would like to achieve the same from Java using wolfSSL JNI. However, when checking the JSSE provider documentation, I only see references to classical algorithms, although there is also mention of the QSH (quantum-safe handshake) extension.

My questions are:
Is wolfSSL_PQC_Hybrids currently supported through wolfssl-jni-jsse?
Is the QSH extension compatible with TLS 1.3 from Java?
If not, are there any plans to expose hybrid key exchange groups in the JNI wrapper?

Any guidance would be greatly appreciated.

How to enable TRNG?

null@example.com (abhmulla) — Tue, 31 Mar 2026 03:44:20 +0000

Hello, I’m relatively new to embedded systems and security, so I appreciate your patience. I am developing a secure file system in a bare metal platform, and for that I am using some encryption algorithms that use a RNG. To initialize the RNG, I used the wc_InitRng function. However, when testing, I received an error relating to the initialization of the RNG. Here, I remembered that my platform does not have an OS. I figured out that it supports RNG through it's hardware (TRNG). This led me to believe that the issue may be related to how wolfSSL expects RNG sources to be configured in a bare-metal environment. However, I couldn't figure out how that can be done.

My question is: How can I configure wolfSSL to use my platform’s hardware TRNG instead of the default RNG implementation?

Any guidance or examples would be greatly appreciated.

Thank you!

how to build wolfssl for gnu-efi?

null@example.com (gomidas95) — Sat, 28 Mar 2026 21:20:28 +0000

I am trying to use wolfssl in my vs gnu-efi project. What are the steps for GNU-EFI ?

Thank you.

Wolfssl fails with error -313 after a series of read write

null@example.com (Edoardo) — Thu, 19 Mar 2026 12:44:12 +0000

wolfSSL_read called from an STM32 microcontroller acting as a Server returns -313 (FATAL ERROR) after many succesfull readings from a CSharp application acting as a Client.

ret = wolfSSL_read(Pt_ssl, A_prcl_msd_m1_m1s_data_link_rx_buffer, sizeof(A_prcl_msd_m1_m1s_data_link_rx_buffer)-1);
err = wolfSSL_get_error(Pt_ssl, ret);

Our receive callback is like this and works fine

wolfSSL_CTX_SetIORecv(Pt_ctx, PRCL_MSD_M1_M1S_DLINK_uartIORx);

/*!
* \brief WolfSSL receive callback
* \dotfile PRCL_MSD_M1_M1S_DLINK_uartIORx.dot
* \ingroup MSD_M1_M1S_PROTOCOL_DATA_LINK
*/
static int PRCL_MSD_M1_M1S_DLINK_uartIORx(WOLFSSL *ssl, char *buf, const int sz, void *ctx)
{
bool b_message_received;
static int8_t * p_data_received_buf;
static int32_t total_amount_data_rcv = 0;
int32_t bytes_available_fifo = 0;
int32_t bytes_to_read;
int32_t bytes_read;

b_message_received = MDL_USARTS_Check_end_reception(USART_MSD_COMMS);

if (b_message_received == TRUE)
{
total_amount_data_rcv = MDL_USARTS_Get_DMA_amount_of_rx_data(USART_MSD_COMMS);
MDL_USARTS_Reset_DMA_amount_of_rx_data(USART_MSD_COMMS);

MDL_USARTS_Start_receive(USART_MSD_COMMS);

p_data_received_buf = (int8_t*)MDL_USARTS_Get_receive_buffer(USART_MSD_COMMS);
MDL_CIRC_FIFO_Fifo_push_buf(&T_wolfSSL_rx_fifo, (uint8_t *)p_data_received_buf, total_amount_data_rcv);
}

bytes_available_fifo = MDL_CIRC_FIFO_Fifo_used_size(&T_wolfSSL_rx_fifo);

if (bytes_available_fifo > 0)
{
DEBUG_PRINTF("FIFO used: %d, DMA received: %d\r\n", bytes_available_fifo, total_amount_data_rcv);
bytes_to_read = (bytes_available_fifo < sz) ? bytes_available_fifo : sz;
bytes_read = MDL_CIRC_FIFO_Fifo_pop_buf(&T_wolfSSL_rx_fifo, (uint8_t *)buf, bytes_to_read);
return bytes_read;
}
else
{
return WOLFSSL_CBIO_ERR_WANT_READ;
}

}

Does anyone has any suggestion?
Many Thanks,
Edoardo

wolfssljni--DTLSv1.2 not recognized

null@example.com (jorgeja) — Thu, 19 Mar 2026 07:29:14 +0000

hi, i was trying to use wolfSSL in a java environment, the build was good, and the native library was load successfully, yet when i try to create a java SSLContext for DTLS by java JSSE, an exception occurred saying that the "java.lang.RuntimeException: java.security.NoSuchAlgorithmException: no such algorithm: DTLSv1.2 for provider wolfJSSE"

AF_ALG breaks certificate verification on ARM32 (-155 error)

null@example.com (adolphson) — Thu, 19 Feb 2026 00:55:09 +0000

Hi,

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.

Getting -125 for the API wolfSSL_CTX_load_verify_buffer()

null@example.com (chiranthanandmurthy) — Tue, 17 Feb 2026 08:42:18 +0000

hi All,

I am using TM4C129X MCU + FreeRTOS TCP+ Wolfssll 5.8.4

i am facing -125 error for this api
wolfSSL_CTX_load_verify_buffer(ctx, (const unsigned char*)ca_cert_pem, strlen(ca_cert_pem), WOLFSSL_FILETYPE_PEM);

Her is my user-settings.h file
/*
* user_settings.h
*
* Created on: 11-Feb-2026
* Author: chira
*/
#ifndef WOLFSSL_USER_SETTINGS_H
#define WOLFSSL_USER_SETTINGS_H

#ifdef __cplusplus
extern "C" {
#endif

/* ===================================================== */
/* Platform */
/* ===================================================== */
#define FREERTOS_TCP
#define SINGLE_THREADED
#define WOLFSSL_SMALL_STACK
#define WOLFSSL_USER_IO

/* Required for TI CGT */
#define NO_INLINE

/* ===================================================== */
/* TLS Configuration */
/* ===================================================== */

#define WOLFSSL_TLS12
#define WOLFSSL_NO_TLS13

#define NO_OLD_TLS
#define NO_SESSION_CACHE
#define NO_WOLFSSL_SERVER /* Client only */
#define HAVE_SNI

/* ===================================================== */
/* Disable Unused Crypto */
/* ===================================================== */

//#define NO_RSA
#define NO_DH
#define NO_DSA
#define NO_DES3
#define NO_RC4
#define NO_MD4
#define NO_PSK
#define NO_FILESYSTEM
#define NO_WRITEV

/* ===================================================== */
/* ECC (Only curve secp256r1) */
/* ===================================================== */

#define HAVE_ECC
#define ECC_USER_CURVES
#undef NO_ECC256

#define ECC_SHAMIR
#define ECC_TIMING_RESISTANT

/* ===================================================== */
/* AES */
/* ===================================================== */

#define HAVE_AES_CBC
#define HAVE_AESGCM
#define GCM_SMALL

/* ===================================================== */
/* Hash */
/* ===================================================== */

//#define NO_SHA
/* Keep SHA enabled */
#define NO_MD5
#define WOLFSSL_SHA256

/* ===================================================== */
/* Math */
/* ===================================================== */

#define USE_FAST_MATH
#define TFM_TIMING_RESISTANT
#define FP_MAX_BITS 4096

/* ===================================================== */
/* Memory */
/* ===================================================== */

//#define NO_WOLFSSL_MEMORY /* use malloc/free */
// #define WOLFSSL_STATIC_MEMORY
// #define WOLFSSL_NO_MALLOC

/* ===================================================== */
/* RNG */
/* ===================================================== */

#define HAVE_HASHDRBG

//extern unsigned int my_rng_seed_gen(void);
//#define CUSTOM_RAND_GENERATE my_rng_seed_gen

/* ===================================================== */
/* Misc */
/* ===================================================== */

#define HAVE_TLS_EXTENSIONS
#define HAVE_SUPPORTED_CURVES

#define HAVE_CERTS
#define WOLFSSL_BASE64_ENCODE
#define WOLFSSL_ASN
#define HAVE_X509

#define WOLFSSL_USER_CURRTIME
#define XTIME time

#ifdef __cplusplus
}
#endif

#endif /* THIRD_PARTY_USER_SETTINGS_H_ */

please guide me where i am getting wrong and also i am attaching my code

Regards
Chiranth Murthy

In case of DTLS 1.3 when using NULL cipher the Nonce length invalid

null@example.com (andras.erdos) — Tue, 10 Feb 2026 13:36:39 +0000

Version
master branch, commit from 2026.02.06 (hash: 25db90...)

Description
I am using DTLS 1.3 with TLS_SHA384_SHA384 (integrity only, NULL cipher)
In this case when the BuildTls13Nonce gets executed, the seq_offset calculated as follows:

int seq_offset = AEAD_NONCE_SZ - SEQ_SZ;

According to my understanding, the seq_offset is variable and should depend on the size of the HMAC Nonce.
In wolfssl this is called HMAC_NONCE_SZ

Explanation:

According to Section 5.3 ("Per-Record Nonce") of RFC 8446 (https://www.rfc-editor.org/rfc/rfc8446#section-5.3):

"The resulting quantity (of length iv_length) is used as the
per-record nonce."

This means that the nonce has to be the same length as the IV.

According to Section 6 ("Key Schedule when Using Integrity-Only Cipher Suites") of RFC 9150 (https://www.rfc-editor.org/rfc/rfc9150.html#section-6), the IV length of TLS_SHA384_SHA384 is 48.

Therefore, these two combined mean that the nonce length in case of TLS_SHA384_SHA384 shall be 48.

wolfssl tls13

null@example.com (jamest) — Thu, 22 Jan 2026 17:31:14 +0000

Hello, I am trying to use tl 1.3 with pkcs11. I am running into an issue when calling wolfSSL_connect(), despite initializing ssl with tls 1.3 client method when wolfSSL_connect() is called "TLS 1.2 or lower" message is sent. This seems to happen in the code at

#ifdef WOLFSSL_TLS13
i (ssl.options.tls1_3) {
return wolfSSL_connect_TLSv13(ssl);
}
#endif

the macro causes the if statement to be called but it fails and wolfSSL_connect_TLSv13(ssL) is not called presumably leading to a version error on the server side. My question is where is ssl.options.tls1_3 set to 1? If it is not explicitly set and just inherits the ctx.options field then where is that happening? I have "--enabled-tls13" as well as set ctx = wolfSSL_CTX_new(wolfTLSv1_3_client_method())) == NULL.
I do want to add when I set both server and client to tls 1.2 methods the connection works.
Below is my options.h configuration.

ifdef WOLFSSL_NO_OPTIONS_H
/* options.h inhibited by configuration */
#elif !defined(WOLFSSL_OPTIONS_H)
#define WOLFSSL_OPTIONS_H

#ifdef __cplusplus
extern "C" {
#endif

#undef WOLFSSL_HAVE_ATOMIC_H
#define WOLFSSL_HAVE_ATOMIC_H

#undef WOLFSSL_HAVE_ASSERT_H
#define WOLFSSL_HAVE_ASSERT_H

#undef HAVE_C___ATOMIC
#define HAVE_C___ATOMIC 1

#undef HAVE_THREAD_LS
#define HAVE_THREAD_LS

#undef DEBUG_WOLFSSL
#define DEBUG_WOLFSSL

#undef WOLFSSL_DEBUG_CODEPOINTS
#define WOLFSSL_DEBUG_CODEPOINTS

#undef WOLFSSL_DEBUG_TRACE_ERROR_CODES
#define WOLFSSL_DEBUG_TRACE_ERROR_CODES

#undef NO_DO178
#define NO_DO178

#undef WOLFSSL_X86_64_BUILD
#define WOLFSSL_X86_64_BUILD

#undef WOLFSSL_ASN_TEMPLATE
#define WOLFSSL_ASN_TEMPLATE

#undef ERROR_QUEUE_PER_THREAD
#define ERROR_QUEUE_PER_THREAD

#undef TFM_TIMING_RESISTANT
#define TFM_TIMING_RESISTANT

#undef ECC_TIMING_RESISTANT
#define ECC_TIMING_RESISTANT

#undef WC_RSA_BLINDING
#define WC_RSA_BLINDING

#undef WOLFSSL_ARMASM_NO_HW_CRYPTO
#define WOLFSSL_ARMASM_NO_HW_CRYPTO

#undef WOLFSSL_USE_ALIGN
#define WOLFSSL_USE_ALIGN

#undef WOLFSSL_SHA224
#define WOLFSSL_SHA224

#undef WOLFSSL_SHA512
#define WOLFSSL_SHA512

#undef WOLFSSL_SHA384
#define WOLFSSL_SHA384

#undef HAVE_HKDF
#define HAVE_HKDF

#undef HAVE_ECC
#define HAVE_ECC

#undef ECC_SHAMIR
#define ECC_SHAMIR

#undef ECC_MIN_KEY_SZ
#define ECC_MIN_KEY_SZ 224

#undef HAVE_ECC_BRAINPOOL
#define HAVE_ECC_BRAINPOOL

#undef HAVE_ECC_ENCRYPT
#define HAVE_ECC_ENCRYPT

#undef NO_OLD_TLS
#define NO_OLD_TLS

#undef WC_RSA_PSS
#define WC_RSA_PSS

#undef WOLFSSL_PSS_LONG_SALT
#define WOLFSSL_PSS_LONG_SALT

#undef WOLFSSL_ASN_PRINT
#define WOLFSSL_ASN_PRINT

#undef WOLFSSL_BASE64_ENCODE
#define WOLFSSL_BASE64_ENCODE

#undef WOLFSSL_CUSTOM_CURVES
#define WOLFSSL_CUSTOM_CURVES

#undef HAVE_ECC_SECPR2
#define HAVE_ECC_SECPR2

#undef HAVE_ECC_SECPR3
#define HAVE_ECC_SECPR3

#undef HAVE_ECC_BRAINPOOL
#define HAVE_ECC_BRAINPOOL

#undef HAVE_ECC_KOBLITZ
#define HAVE_ECC_KOBLITZ

#undef HAVE_ECC_CDH
#define HAVE_ECC_CDH

#undef WOLFSSL_SHA3
#define WOLFSSL_SHA3

#undef WOLFSSL_NO_SHAKE128
#define WOLFSSL_NO_SHAKE128

#undef WOLFSSL_NO_SHAKE256
#define WOLFSSL_NO_SHAKE256

#undef HAVE_POLY1305
#define HAVE_POLY1305

#undef HAVE_CHACHA
#define HAVE_CHACHA

#undef HAVE_HASHDRBG
#define HAVE_HASHDRBG

#undef HAVE_TLS_EXTENSIONS
#define HAVE_TLS_EXTENSIONS

#undef HAVE_SNI
#define HAVE_SNI

#undef HAVE_TLS_EXTENSIONS
#define HAVE_TLS_EXTENSIONS

#undef HAVE_SUPPORTED_CURVES
#define HAVE_SUPPORTED_CURVES

#undef HAVE_FFDHE_2048
#define HAVE_FFDHE_2048

#undef HAVE_SUPPORTED_CURVES
#define HAVE_SUPPORTED_CURVES

#undef WOLFSSL_TLS13
#define WOLFSSL_TLS13

#undef HAVE_TLS_EXTENSIONS
#define HAVE_TLS_EXTENSIONS

#undef HAVE_EXTENDED_MASTER
#define HAVE_EXTENDED_MASTER

#undef HAVE_TLS_EXTENSIONS
#define HAVE_TLS_EXTENSIONS

#undef HAVE_SNI
#define HAVE_SNI

#undef HAVE_MAX_FRAGMENT
#define HAVE_MAX_FRAGMENT

#undef HAVE_TRUNCATED_HMAC
#define HAVE_TRUNCATED_HMAC

#undef HAVE_ALPN
#define HAVE_ALPN

#undef HAVE_TRUSTED_CA
#define HAVE_TRUSTED_CA

#undef HAVE_SUPPORTED_CURVES
#define HAVE_SUPPORTED_CURVES

#undef NO_RC4
#define NO_RC4

#undef HAVE_ENCRYPT_THEN_MAC
#define HAVE_ENCRYPT_THEN_MAC

#undef NO_PSK
#define NO_PSK

#undef NO_MD4
#define NO_MD4

#undef WOLFSSL_ENCRYPTED_KEYS
#define WOLFSSL_ENCRYPTED_KEYS

#undef HAVE_PKCS11
#define HAVE_PKCS11

#undef HAVE_WOLF_BIGINT
#define HAVE_WOLF_BIGINT

#undef WOLFSSL_SP_MATH_ALL
#define WOLFSSL_SP_MATH_ALL

#undef WOLFSSL_SP_X86_64
#define WOLFSSL_SP_X86_64

#undef WOLF_CRYPTO_CB
#define WOLF_CRYPTO_CB

#undef WC_NO_ASYNC_THREADING
#define WC_NO_ASYNC_THREADING

#undef HAVE_DH_DEFAULT_PARAMS
#define HAVE_DH_DEFAULT_PARAMS

#undef HAVE_CURVE25519
#define HAVE_CURVE25519

#undef HAVE_ED25519
#define HAVE_ED25519

#undef WOLFSSL_SYS_CA_CERTS
#define WOLFSSL_SYS_CA_CERTS

#undef OPENSSL_EXTRA
#define OPENSSL_EXTRA

#undef NO_DES3
#define NO_DES3

#undef NO_DES3_TLS_SUITES
#define NO_DES3_TLS_SUITES

#undef GCM_TABLE_4BIT
#define GCM_TABLE_4BIT

#undef HAVE_AESGCM
#define HAVE_AESGCM

#undef WOLFSSL_AESGCM_STREAM
#define WOLFSSL_AESGCM_STREAM

#undef HAVE_TLS_EXTENSIONS
#define HAVE_TLS_EXTENSIONS

#undef HAVE_SERVER_RENEGOTIATION_INFO
#define HAVE_SERVER_RENEGOTIATION_INFO

#undef HAVE___UINT128_T
#define HAVE___UINT128_T 1

#undef HAVE_GETPID
#define HAVE_GETPID 1

#undef HAVE_WC_INTROSPECTION
#define HAVE_WC_INTROSPECTION

#ifdef __cplusplus
}
#endif

#endif /* WOLFSSL_OPTIONS_H */

how to integrate Mongoose(v7.20) with wolfSSL(v5.8.4)

null@example.com (andy_liu) — Wed, 21 Jan 2026 09:25:46 +0000

hi,
I want to integrate two open-source libraries to implement a simple HTTPS server for testing purposes:
Mongoose(v7.20)
https://github.com/cesanta/mongoose
wolfSSL(v5.8.4)
https://github.com/wolfSSL/wolfssl
My development environment:
PC (X86/WINDOWS11), VSCODE, gcc(tasks.json);
I found it very difficult to achieve.
Is there a similar demo available for reference?
tks!

wolfssl_AES_CTR example no longer compiles for Teensy 4.1

null@example.com (chrisj7903) — Mon, 19 Jan 2026 20:49:01 +0000

I've come across an issue compiling with the latest wolfssl 5.8.4 arduino library on Teensy 4.1

The wolfssl_AES_CTR example included in the library compiles with no issues for Teensy Micromod, but not for Teensy 4.1 ?

This would compiile for both Teensy models on the earlier wolfssl 5.7.6 library last year, so this is somewhat puzzling. See attached the compilation output.

What could be causing this?

TIA