You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → Posts by Sunnysunday
Pages 1
In DTLS1.3 the key exchange (key share) is no longer specified in the Cipher Suite but it's negotiated separately via the Supported Groups and KeyShare extensions in the ClientHello and ServerHello.
I don't know right now if the key share is shown in the logs, I would have to check, but I always check with a Wireshark packet capture anyway and there you can see which key share was actually used.
I have been conducting tests using wolfssl with ML-KEM PQC on Nordic hardware, measuring DTLS Handshake duration and power consumption.
With the long keys being generated in ML_KEM_512 (800 Bytes with ML_KEM vs 65 with ECDHE), I was expecting much longer handshake times and overall reduced performance compared to normal ECC_SECP256R1, but my measurements indicate that performance is about equal (Cipher Suite TLS13-AES128-GCM-SHA256 with 128 Bit PSK).
Can this be? What's your experience at Wolfssl with ML_KEM_512 Performance compared to ECDHE?
I thought maybe there is something wrong with my setup.
I enforce ML_KEM_512 with two Wolfssl function like this on the client side:
wolfSSL_CTX_UseSupportedCurve(ctx, WOLFSSL_ML_KEM_512);
wolfSSL_UseKeyShare(ssl, WOLFSSL_ML_KEM_512);In Wireshark I see the approximately 800 Byte keys being sent in client hello and server hello, so I guess my setup is working. This is the Server Hello:
Datagram Transport Layer Security
DTLSv1.3 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: DTLS 1.2 (0xfefd)
Epoch: 0
Sequence Number: 0
Length: 840
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 828
Message Sequence: 0
Fragment Offset: 0
Fragment Length: 828
Version: DTLS 1.2 (0xfefd)
[Expert Info (Chat/Deprecated): This legacy_version field MUST be ignored. The supported_versions extension is present and MUST be used instead.]
[This legacy_version field MUST be ignored. The supported_versions extension is present and MUST be used instead.]
[Severity level: Chat]
[Group: Deprecated]
Random: 999619785a3ac2ea78c817e21c867cb34c60170ba578b15102d54c1c35b7f4d4
Session ID Length: 0
Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
Compression Method: null (0)
Extensions Length: 788
Extension: pre_shared_key (len=2)
Type: pre_shared_key (41)
Length: 2
Pre-Shared Key extension
Selected Identity: 0
Extension: key_share (len=772) MLKEM512
Type: key_share (51)
Length: 772
Key Share extension
Key Share Entry: Group: MLKEM512, Key Exchange length: 768
Group: MLKEM512 (512)
Key Exchange Length: 768
Key Exchange […]: 443a003543a7c73daa189d1a15463e1f22db158ff72744f7eccbcac8608f8d920ac37c5086c6e47bd83d62521b25199a0981dddcc5a6f0cba81c2f42cca888d916243787da19052b30a29892a9bca9a11bbc4ec82a80bbf1f18c98857d08ac7a2513b2a7fbdbe4d7f9e49938daf
Extension: supported_versions (len=2) DTLS 1.3
Type: supported_versions (43)
Length: 2
Supported Version: DTLS 1.3 (0xfefc)
[JA3S Fullstring: 65277,4865,41-51-43]
[JA3S: 671c44eba0297291f3364ac4756f7253]So is it expected that ML_KEM512 would perform about the same compared to ECDHE or must there be something I have missed in my measurements?
Thanks, that worked.
I have created a dilithium key pair with wolfclu.
wolfssl -genkey dilithium -level 2 -out dilithium_key -outform der -output keypair
Now how do I create and self sign a x.509 certificate with Dilithium?
I tried various commands, such as
wolfssl -req -new -key dilithium_key.priv -keyform der -out dilithium_req.pem -outform pem
but getting ASN no Header errors, etc.
I am trying Dilithium with wolfssl on Zephyr.
I added
#define HAVE_DILITHIUM
which results in errors.
E.g.:
'DILITHIUM_LEVEL5_PUB_KEY_SIZE' undeclared here (not in a function); did you mean 'DILITHIUM_MAX_PUB_KEY_SIZE'?
C:/ncs/v3.1.0/modules/crypto/wolfssl/src/ssl.c:6029:21: error: 'ML_DSA_LEVEL2_KEY_SIZE' undeclared (first use in this function); did you mean 'ML_DSA_LEVEL2_TYPE'?
6029 | ML_DSA_LEVEL2_KEY_SIZE < (word16)cm->minDilithiumKeySz)
and plenty of there errors related to: DILITHIUM_LEVEL5_PUB_KEY_SIZE, DILITHIUM_LEVEL5_KEY_SIZE, DILITHIUM_LEVEL5_SIG_SIZE
ML_DSA_LEVEL{2,3,5}_KEY_SIZE
Do I need to add extra includes?
I have tried the algorithms you mentioned. Some of them work, most of them throw errors.
These throw missing extension errors, as the client sends no key in the client hello:
WOLFSSL_ML_KEM_1024
WOLFSSL_SECP256R1MLKEM768
These return bad function argument errors:
WOLFSSL_SECP384R1MLKEM768
WOLFSSL_X25519MLKEM768
WOLFSSL_SECP384R1MLKEM1024
WOLFSSL_SECP521R1MLKEM1024
WOLFSSL_X448MLKEM768
These work:
WOLFSSL_SECP256R1MLKEM512
WOLFSSL_ML_KEM_512
WOLFSSL_X25519MLKEM512
WOLFSSL_ML_KEM_768
What could be the reason for the client sending no key in the client hello and for the bad function argument errors?
Thank you.
I am trying this on Zephyr but I can't get it to compile with any of the groups you suggested. I used e.g.
wolfSSL_UseKeyShare(ssl, WOLFSSL_ML_KEM_512);To include Wolfssl in my Zephyr build I was following the official Wolfssl Zephyr Documentation on https://github.com/wolfSSL/wolfssl/tree/master/zephyr and have the settings under manifest in west.yml as described there.
Are there any specific includes I need to use?
I tried those:
#define HAVE_KYBER
#define HAVE_ML_KEM
#define WOLFSSL_HAVE_HYBRID
#define HAVE_ML_DSA
#define WOLFSSL_DTLS_CH_FRAGThose don't throw an error but
wolfSSL_UseKeyShare(ssl, WOLFSSL_ML_KEM_512)
does:
error: 'WOLFSSL_ML_KEM_512' undeclared.
I tried #define HAVE_PQC which also throws an error:
#error Please do not define HAVE_PQC yourself.
Are there any other includes I need to use?
Or do I need to intregrate LIBOQS in some way?
I would like to try Kyber key generation and I am wondering where to set this in my application.
I have set #define HAVE_KYBER and now I want my client to use it. Is that done via setting a special cipher suite with wolfSSL_CTX_set_cipher_list() or via elliptic curve groups or some other way?
Hi Anthony,
Thank you for your answer. My project is academic. I am integrating wolfssl into an application on the nRF9160dk.
With
#define WOLFSSL_TRACK_MEMORY
I get a compile error:
In file included from C:/ncs/v2.8.0/modules/crypto/wolfssl/wolfcrypt/src/wc_port.c:31:
C:/ncs/v2.8.0/modules/crypto/wolfssl/wolfssl/wolfcrypt/mem_track.h: In function 'TrackMalloc':
C:/ncs/v2.8.0/modules/crypto/wolfssl/wolfssl/wolfcrypt/mem_track.h:181:29: error: 'memLock' undeclared (first use in this function)
if (pthread_mutex_lock(&memLock) == 0)Is memlock a variable I need to declare in my user_settings file or in main.c?
I am using wolfssl on Zephyr and would like to check the RAM usage during runtime, in particular the maximum RAM used during a DTLS Handshake.
Is there a way to do that in wolfssl?
I am using wolffssl on a Nordic nRF9160dk board and I would like to try out hardware crypto.
Both wolfssl and the board seem to support cryptocell.
I have tried #define WOLFSSL_CRYPTOCELL, which gives me a compile error:
fatal error: sns_silib.h: No such file or directory
32 | #include "sns_silib.h"
Does that indicate I need to do something on the wolfssl side or rather on the nordic end?
Thank you for the answer.
Is there a function to list all currently enabled cipher suites in my WOLFSSL?
Also, is there a way to enforce specific elliptic curves on cipher suites using DHE other than the ones currently usable with wolfSSL_UseSupportedCurve(), e.g. I would like the client to only present CURVE25519 (or the server to only accept that curve).
I don't understand why my DTLS 1.2 server is rejecting a cipher suite it is apparently supporting.
On the client side I have this:
wolfSSL_CTX_set_cipher_list(ctx, "DHE-PSK-AES128-CBC-SHA256");In wireshark I see this cipher suite being offered:
Cipher Suite: TLS_DHE_PSK_WITH_AES_128_CBC_SHA256 (0x00b2)On the server side with
wolfSSL_get_ciphers(cipher_buffer, BUFFER_SIZE);
I see that the particular cipher is enabled:
DHE-PSK-AES128-CBC-SHA256I do however get a -501 error from the server. What could be wrong?:
wolfSSL Leaving DoClientHello, return -501
[15:33:43.709690] wolfSSL Leaving DoHandShakeMsgType(), return -501
[15:33:43.709696] wolfSSL Leaving DoDtlsHandShakeMsg(), return -501
[15:33:43.709702] wolfSSL Entering SendAlert
[15:33:43.709708] wolfSSL Entering SendAlert
[15:33:43.709714] SendAlert: 40 handshake_failure
[15:33:43.709720] growing output buffer
[15:33:43.709727] wolfSSL Entering EmbedSendTo
[15:33:43.710274] Shrinking output buffer
[15:33:43.710295] wolfSSL Leaving SendAlert, return 0
[15:33:43.710307] wolfSSL error occurred, error = 501 line:22167 file:src/internal.c
[15:33:43.710314] wolfSSL error occurred, error = 501 line:10166 file:src/ssl.c
[15:33:43.710323] wolfSSL Entering wolfSSL_get_error
[15:33:43.710329] wolfSSL Leaving wolfSSL_get_error, return -501
Great, thank you.
I have a DTLS client using wolfssl on Zephyr and a server on debian on which I have used the ./configure script to build wolfssl, with these options:
./configure --enable-debug --enable-dtls --enable-dtls13 --enable-dtlscid --enable-debug --enable-dtls --enable-dtls13 --enable-dtlscid --enable-opensslextra --enable-pskSome cipher suites I see are only available on the client side (I check via wolfSSL_get_ciphers()), so I know wolfssl supports them, but are not enabled on the server side.
What ./configure option should I use to enable the following ciphers:
PSK-AES128-GCM-SHA256
PSK-AES128-CBC-SHA256
Thank you.
I'm using WolfSSL's Connection ID in a DTLS setup and need to maintain session continuity when the client's IP changes mid-session. I understand that Connection ID should ideally allow packets to be identified with an existing session even if the IP changes.
However, when this happens, I get "Ignored packet from invalid peer" errors. Do I need to implement additional logic to associate new packets with the existing session manually, or should WolfSSL handle this by default with Connection ID?
Does the WolfSSL port for Zephyr support the DTLS Connection ID feature?
I’m aware that the mainline WolfSSL library supports Connection ID in its latest releases, but I want to confirm if this functionality is available and stable in the Zephyr environment.
Hi,
Thanks for answer. That's good news!
I am a student of computer science writing a Bachelor Thesis on the performance of DTLS (both v1.2 and v1.3) with and without ConnectionID over Narrowband-IoT networks. I will be using the Nordic Thingy:91 and wolfSSL to test that with CoAP data.
Is ConnectionID in WolfSSL only supported for DTLSv1.3 and not for DTLS1.2?
Pages 1
wolfSSL - Embedded SSL Library → Posts by Sunnysunday
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.007 seconds (69% PHP - 31% DB) with 4 queries