wolfCrypt opaque struct sizes vary with build configuration: WOLF_CRYPTO_CB adds devId, devCtx, and devKey fields to key types; platform word size and enabled algorithm sets affect others. FFI wrappers (Rust, Python ctypes, etc.) cannot safely stack-allocate these structs without knowing their exact size for each build configuration, and running bindgen per configuration is fragile and expensive.
Affected structs: Aes, WC_RNG, Poly1305, ChaCha, ChaChaPoly_Aead, ed25519_key, curve25519_key, ed448_key, curve448_key, dilithium_key, LmsKey, XtsAes, Hpke, and others.
Current workaround in use: Each struct is allocated as a [u8; N] byte array with a manually chosen over-approximation of N. Build-time _Static_assert checks verify the approximation hasn't been exceeded:
_Static_assert(sizeof(Aes) <= 512, "Aes exceeds WC_AES_ALLOC_SIZE");
_Static_assert(_Alignof(Aes) <= 16, "Aes alignment exceeds align(16)");
When a wolfSSL upgrade changes a struct size, the build fails with a diagnostic and only two constants need updating. This works but requires manual maintenance each release.
Requested fix (either option would significantly help FFI consumers):
- A) Provide heap-allocate-and-return APIs for opaque types (
Aes* wc_AesNew(), void wc_AesFree(Aes*)), like OpenSSL's EVP_CIPHER_CTX_new(). Cleanest long-term solution; no caller needs to know the struct size.
- B) Export size accessor functions (
wc_AesSize(), wc_RngSize(), etc.) that return sizeof(T) at runtime, allowing FFI wrappers to query the correct allocation size without bindgen.
Migrated from internal tracking (ZD-21740).
wolfCrypt opaque struct sizes vary with build configuration:
WOLF_CRYPTO_CBaddsdevId,devCtx, anddevKeyfields to key types; platform word size and enabled algorithm sets affect others. FFI wrappers (Rust, Python ctypes, etc.) cannot safely stack-allocate these structs without knowing their exact size for each build configuration, and running bindgen per configuration is fragile and expensive.Affected structs:
Aes,WC_RNG,Poly1305,ChaCha,ChaChaPoly_Aead,ed25519_key,curve25519_key,ed448_key,curve448_key,dilithium_key,LmsKey,XtsAes,Hpke, and others.Current workaround in use: Each struct is allocated as a
[u8; N]byte array with a manually chosen over-approximation of N. Build-time_Static_assertchecks verify the approximation hasn't been exceeded:When a wolfSSL upgrade changes a struct size, the build fails with a diagnostic and only two constants need updating. This works but requires manual maintenance each release.
Requested fix (either option would significantly help FFI consumers):
Aes* wc_AesNew(),void wc_AesFree(Aes*)), like OpenSSL'sEVP_CIPHER_CTX_new(). Cleanest long-term solution; no caller needs to know the struct size.wc_AesSize(),wc_RngSize(), etc.) that returnsizeof(T)at runtime, allowing FFI wrappers to query the correct allocation size without bindgen.Migrated from internal tracking (ZD-21740).