matemagico13 wrote:Hello,
I'm working on a DTLS 1.3 server using the wolfSSL library. I'm trying to implement a post-quantum connection using ML-KEM and Dilithium.
I've modified the C code for the server (https://github.com/wolfSSL/wolfssl-exam … r-dtls13.c ball orbit) and client (https://github.com/wolfSSL/wolfssl-exam … t-dtls13.c) .I've added the following for it to use ML-KEM 1024 in both client and server implementations.
/* Create the WOLFSSL Object */
if ((ssl = wolfSSL_new(ctx)) == NULL) {
fprintf(stderr, "wolfSSL_new error.\n");
goto cleanup;
}
/* new code */
ret = wolfSSL_UseKeyShare(ssl, WOLFSSL_ML_KEM_1024);
if (ret < 0) {
fprintf(stderr, "ERROR: failed to set the requested group to "
"WOLFSSL_ML_KEM_1024.\n");
ret = -1;
goto cleanup;
}
When I run the client and connect to the server, the server successfully establishes a connection, and the output shows:
New connection established using DTLSv1.3 TLS_AES_256_GCM_SHA384
I'm confused because this output only specifies the symmetric cipher suite. It doesn't explicitly confirm that ML-KEM was used.
Is there a way to verify through the wolfSSL logs or API that ML-KEM 1024 was used? Thanks in advance for any insight and sorry if this is out of place.
You’re right — the cipher suite string you’re seeing (TLS_AES_256_GCM_SHA384) only describes the negotiated symmetric cipher, not the key exchange mechanism. In TLS 1.3/DTLS 1.3, the KEM or key exchange group is negotiated separately and doesn’t show up in the cipher suite line.
With wolfSSL, there are a couple of ways you can confirm that ML-KEM 1024 is actually being used:
Enable verbose debugging logs
Call:
wolfSSL_Debugging_ON();
before creating the context. This will dump detailed handshake logs to stderr, including the “key_share” extension negotiation. If ML-KEM 1024 is chosen, you’ll see it logged during the ClientHello/ServerHello exchange.
Query the group in use via the API
After the handshake, you can call:
int group = wolfSSL_GetNegotiatedGroup(ssl);
printf("Negotiated group: %d\n", group);
For post-quantum groups, this should return WOLFSSL_ML_KEM_1024 (or the corresponding enum value). That way, you can explicitly check what group was used.
Check the handshake trace with Wireshark
If you capture the DTLS handshake, you should see the key_share extension containing ML-KEM 1024 parameters in the ClientHello and ServerHello. That gives you external confirmation independent of wolfSSL.
So in short: the “AES_256_GCM_SHA384” part is normal, and you’ll need either wolfSSL debug logs, wolfSSL_GetNegotiatedGroup(), or a packet trace to verify that the ML-KEM 1024 group was negotiated.