Contact Details
alessandro.bertea@rub.de
Version
5.9.1
Description
When a client sends multiple key shares that include a mix of hybrid PQC and pure ML-KEM (e.g. SecP384R1_MLKEM1024 + MLKEM1024), the server side handling in wolfSSL appears to be order-dependent and leads to handshake failure.
I tested two ClientHello key_share orderings:
** Case 1 **
key_share: [hybrid group, mlkem_group]
- Server selects hybrid group and sends its key_share in ServerHello
- Decryption of records on client side fail
- Evidence of state corruption: Debug logs show the derived
KE Secret on the wolfSSL side is only 32 bytes long despite the server sending SecP384R1_MLKEM1024 as its key_share.
** Case 2 **
key_share: [mlkem_group, hybrid_group]
- Server outputs
SSL_accept error -132, Buffer error, output too small or input too big
- Server terminates connection
Expected Behavior
- The server should parse all key shares safely
- The server should select a single key share preference
- It should perform the key exchange math only once, based on the selected group
- Behavior should be strictly independent of key share ordering
Suspected Root Cause
In TLSX_KeyShareEntry_Parse():
ret = TLSX_KeyShare_Use(ssl, group, keLen, ke, kse, extensions);
For PQC/hybrid groups on the server side, TLSX_KeyShare_Use() (or the block immediately preceding it) appears to perform the PQC encapsulation eagerly during the parsing phase. The resulting shared secret is written directly into the global handshake state.
Because there is no "final selection" phase that separates parsing from math execution, processing multiple PQC key shares causes wolfSSL to recompute and destructively overwrite previously computed cryptographic values and buffers
There does not appear to be a guard preventing multiple key shares from:
- Recomputing the shared secret
- Overwriting previously computed values
Reproduction steps
- Configure wolfSSL with hybrid and pure ML-KEM enabled
- Use the built-in test server
- Send crafted ClientHello with multiple key shares:
- One hybrid group (e.g. SecP384R1_MLKEM1024)
- One pure PQC group (e.g. MLKEM1024)
Relevant log output
Contact Details
alessandro.bertea@rub.de
Version
5.9.1
Description
When a client sends multiple key shares that include a mix of hybrid PQC and pure ML-KEM (e.g. SecP384R1_MLKEM1024 + MLKEM1024), the server side handling in wolfSSL appears to be order-dependent and leads to handshake failure.
I tested two ClientHello key_share orderings:
** Case 1 **
key_share: [hybrid group, mlkem_group]
KE Secreton the wolfSSL side is only 32 bytes long despite the server sendingSecP384R1_MLKEM1024as its key_share.** Case 2 **
key_share: [mlkem_group, hybrid_group]
SSL_accept error -132, Buffer error, output too small or input too bigExpected Behavior
Suspected Root Cause
In
TLSX_KeyShareEntry_Parse():ret = TLSX_KeyShare_Use(ssl, group, keLen, ke, kse, extensions);For PQC/hybrid groups on the server side,
TLSX_KeyShare_Use()(or the block immediately preceding it) appears to perform the PQC encapsulation eagerly during the parsing phase. The resulting shared secret is written directly into the global handshake state.Because there is no "final selection" phase that separates parsing from math execution, processing multiple PQC key shares causes wolfSSL to recompute and destructively overwrite previously computed cryptographic values and buffers
There does not appear to be a guard preventing multiple key shares from:
Reproduction steps
Relevant log output