51

(1 replies, posted in wolfSSL)

Hello Mike,

Yes, your understanding of PSK is correct.  I would recommend using PSK with ECDHE for this reason, if feasible.  TLS 1.3 does generally offer forward secrecy, but there are cases where you would want to use PSK only, so it is still offered despite not offering forward secrecy.

You can turn on debug logging in wolfSSL to confirm the key exchange and connection are being completed as expected by building wolfSSL with --enable-debug.  You could also capture a packet dump and open it with Wireshark to confirm everything being sent and received matches your expectations.

You may find our PSK examples and documentation here helpful: https://github.com/wolfSSL/wolfssl-exam … master/psk

Thanks,
Kareem

52

(2 replies, posted in wolfSSL)

Hello gsojc234,

wolfSSL is maintaining a rolling hash, which is updated after each message.  Even though you will only see the hash using the current message's data when we are constructing the Finished message, it is using the hash computed from previous messages.
In some cases, we keep handshake data until after Finished is sent to compute this hash.
For more information on how we are doing this, check out the functions HashInput, HashOutput and HashRaw in internal.c.

Thanks,
Kareem

53

(5 replies, posted in wolfCrypt)

Hi OptiZle,

The examples include a user_settings.h which is tuned for the ESP32, I would recommend retrying with this.  Our generic user_settings_default.h file is meant as a reference, and is not suitable out of the box for the ESP32.

Yes, we've recently improved our ESP32 support and added support for the S3.  I don't believe this support was present in 5.5.4.  I would strongly recommend upgrading.

Thanks,
Kareem

54

(5 replies, posted in wolfCrypt)

Hi OptiZle,

Thanks for reaching out to us.

-199 is RNG_FAILURE_E, which means we had an issue initializing your RNG.
What version of wolfSSL are you using, and what settings are you using to build wolfSSL?  Have you tried using our Espressif example found here: https://github.com/wolfSSL/wolfssl/tree … if/ESP-IDF ?  If not, I would recommend using it.  Make sure you're using our latest version, 5.6.3.

Thanks,
Kareem

55

(2 replies, posted in wolfCrypt)

Hi lazH,

Your code is currently passing in the entire certificate DER to wc_RsaPublicKeyDecode, this won't work as wc_RsaPublicKeyDecode expects just the key.
You will need to call wolfSSL_X509_load_certificate_file followed by wolfSSL_X509_get_pubkey on your certificate to extract the public key.  You can then call wc_RsaPublicKeyDecode on this extracted public key and use it as desired for encryption/decryption.
Check out our full example of this here: https://github.com/wolfSSL/wolfssl-exam … m-certfile

Thanks,
Kareem

56

(2 replies, posted in wolfCrypt)

Hi pbreed,

We do not directly support generating a JSON web key, but we do support generating keys, exporting their components and encoding them as base64.  After following these steps, you will need to handle creating the JSON and adding the base64-encoded components to this JSON.

For RSA:
1)  Generate an RSA key using wc_MakeRsaKey: https://www.wolfssl.com/documentation/m … makersakey
2)  Export the RSA key using wc_RsaFlattenPublicKey (n/e only for public key) or wc_RsaExportKey (all components for public + private key): https://www.wolfssl.com/documentation/m … npublickey

For ECC:
1)  Generate an ECC key using wc_ecc_make_key: https://www.wolfssl.com/documentation/m … c_make_key
2)  Export the ECC key using wc_ecc_export_public_raw/wc_ecc_export_private_raw.

Now base64 encode each component using Base64_Encode_NoNl: https://www.wolfssl.com/documentation/m … ncode_nonl

Then you will need to create the appropriate JSON and add these components.

Thanks,
Kareem

57

(3 replies, posted in wolfSSL)

Hi ajmal,

You can use our user_settings.h to disable all features which are not needed for your use case.  You can find a documented example of our common settings here: https://github.com/wolfSSL/wolfssl/blob … template.h

For us to give personalized size optimization support, we would need a paid support agreement in place.  If you are interested, please let me know where you are located, and I will connect you with your region's sales rep.

Thanks,
Kareem

58

(3 replies, posted in wolfMQTT)

Hi b.stefano,

It looks like Microchip Harmony is currently providing wolfSSL 5.4.0 and wolfMQTT 1.11.1.  While these versions are outdated, I would expect them to work.  Are these the versions you are seeing in your Microchip Harmony project?

What build errors are you seeing from wolfSSL/wolfMQTT?

Thanks,
Kareem

59

(2 replies, posted in wolfCrypt)

Hi m_u_h,

To force a failed FIPS POST state, build wolfSSL with HAVE_FORCE_FIPS_FAILURE defined, then at runtime, call wolfCrypt_SetStatus_fips(DRBG_CONT_FIPS_E).

Thanks,
Kareem

60

(1 replies, posted in wolfMQTT)

Hello Fernando,

Check out our MQTT client example here for a general example of how to handle reads: https://github.com/wolfSSL/wolfMQTT/tre … mqttclient
We also have other examples in examples/ which you may find helpful: https://github.com/wolfSSL/wolfMQTT/tre … r/examples

Thanks,
Kareem

61

(1 replies, posted in wolfSSL)

Hi singhshikha,

We do rely on some system calls such as closesocket, htons etc.  Please confirm you are linking in your standard library.  If so, you will need to provide wolfSSL with your OS' equivalent to these functions.  We check if our function aliases such as CloseSocket have been defined, which allows you to override them by defining them in your user_settings.h:

#define CloseSocket(s) YourCloseSocketFn(s)
#define XHTONS(a) YourHtoNsFn((a))
#define XINET_PTON(a,b,c)   YourInet_PtonFn((a),(b),(c))
#define DTLS_RECVFROM_FUNCTION YourRecvFromFn
#define DTLS_SENDTO_FUNCTION YourSendToFn

If you don't have any of these functions, you'll need to define a wrapper function instead which provides equivalent functionality.
setsockopt, getpeername and getsockopt are currently called directly in our code and can't be overridden.
WSAGetLastError is coming from USE_WINDOWS_API, don't define this if you don't have Windows API support.

If you continue to run into issues, please reach out to us at support AT wolfssl DOT com with your user_settings.h.  It would also be helpful to know what kind of system calls your OS has available.

I recommend upgrading to our latest release 5.6.0 when feasible for the best support and performance.

Thanks,
Kareem

Hi akimoorthy,

Yes, you will definitely need ECC to achieve this size.  You will want to use 256-bit ECC to generate a public key less than 72 bytes in size.  Note that while the key itself will be smaller than 72 bytes, you are using a PFX file (PKCS#12) which will add some overhead.  For minimal size, consider using a DER file, which will only contain the key itself.

Here is a full example of how to generate an ECC keypair and export it to .der files: https://github.com/wolfSSL/wolfssl-exam … y-export.c

63

(5 replies, posted in wolfSSL)

Hello avlec,

Yes, this is expected.  As part of certificate validation, we ensure that the current system time falls between the notBefore and notAfter dates from the certificate.  To perform this check, the system time must be set correctly before running wolfSSL.
We get the current system time using gmtime_s, gmtime_r or gmtime, depending on which is available on the system.  It's possible that glibc supports a gmtime call which musl does not, which is causing the behavior difference you are seeing.
You can run strace on your application to confirm which time call we are using, and whether it is returning a valid date.

Thanks,
Kareem

64

(5 replies, posted in wolfSSL)

Hello avlec,

Please retry with our latest release, 5.6.0, and let me know if it helps.
If not, please enable debug logging in wolfSSL and attach a debug log here.  To enable debug logging, build wolfSSL with --enable-debug and run wolfSSL_Debugging_ON() at the start of your program.
Please also include your build config (./configure line).

Thanks,
Kareem

65

(1 replies, posted in wolfSSL)

Hi Tom,

Version error/-326 means the client and server were unable to match TLS versions.
Most likely, your server needs a TLS version you are not building with.  By default, we only enable TLS 1.2 and 1.1.
I would start with TLS 1.3, which you can enable by defining WOLFSSL_TLS13 HAVE_TLS_EXTENSIONS and HAVE_SUPPORTED_CURVES in your user_settings.h.
If instead you need TLS 1.0, you can define WOLFSSL_ALLOW_TLSV10 to enable this.

If you still have issues, please confirm how you are setting up your wolfSSL context, for example ctx = wolfSSL_CTX_new(wolfSSLv23_client_method()).  Try using wolfSSLv23_client_method() if you aren't already, as this allows us to select the TLS version at connect time.

Thanks,
Kareem

66

(6 replies, posted in wolfSSL)

Our date check is failing: Date BEFORE check failed
This normally happens when your system time (RTC) is not set correctly, are you confident this is set correctly on your system?
Note that, on Zephyr we use clock_gettime with a clock ID of CLOCK_REALTIME.  I would confirm this is returning the correct time for you.  See z_time in wolfcrypt/src/wc_port.c.

67

(6 replies, posted in wolfSSL)

Hi,

Please enable wolfSSL debug logging by defining CONFIG_WOLFSSL_DEBUG/DEBUG_WOLFSSL and attach a debug log here.
Please also attach the cert you are trying to register.
If this is sensitive information, please contact us at support [AT] wolfssl [dot] com.

68

(2 replies, posted in wolfCrypt)

Yes, if you want cURL to use FIPS crypto, it needs to be built against wolfCrypt FIPS.

69

(6 replies, posted in wolfSSL)

Hi ajmal,

Yes, that is certainly a valid approach.  But of course, you should not need any workarounds ideally.
Can you please confirm which wolfSSL version you're on, and what toolchain you're using?  This will assist us in fixing this upstream.

Thanks,
Kareem

70

(4 replies, posted in wolfSSL)

Scotty,

I can assist you with bringing up net-SNMP with wolfSSL, but I'm afraid SNMP itself is outside of our support, as we do not directly support this protocol.  wolfSSL is only providing cryptography to net-SNMP.

Thanks,
Kareem

71

(4 replies, posted in wolfSSL)

Hello Scott,

We provide SNMP support via a net-SNMP patch: https://github.com/wolfSSL/osp/blob/mas … .9.1.patch
You will find instructions on how to use the patch at the top of the patch file, in the comment block.
You will need a utility like "patch" or "git apply" to apply the patch file.

Thanks,
Kareem

Hi Bassem,

wc_KeyPemToDer is meant for private keys, you're getting -162 (ASN_NO_PEM_HEADER) for your public key as it specifically checks for private key headers only.  For public keys, you can use wc_PubKeyPemToDer.  You can also use wc_PemToDer as a general PEM to DER conversion function.

Thanks,
Kareem

Hi mamonetti,

Thanks for sharing and for your patience.

Your wolfSSL build settings look good to me.  The problem is Harmony is shipping an outdated wolfSSL release.  I do recognize the wolfSSL_read issue you are seeing, it should be fixed by this PR: https://github.com/wolfSSL/wolfssl/pull/4203  However, rather than cherry-picking it, I would strongly recommend you upgrade to our latest release, 5.5.3, for the best security and functionality.  You can find our latest release in our Github repo: https://github.com/wolfSSL/wolfssl/releases

You will need to register the appropriate CA certificates on startup for our verification to succeed, please retry after adding your CA certificates.

Yes, you can toggle our CA checking at runtime using wolfSSL_set_verify.  Set the second parameter to SSL_VERIFY_PEER to enable validation, SSL_VERIFY_NONE to disable it.  We strongly recommend against using SSL_VERIFY_NONE in production, as it removes a lot of the benefit of SSL.  You can find more information on wolfSSL_set_verify here: https://www.wolfssl.com/documentation/m … set_verify

Please let me know if you have any further questions.

Thanks,
Kareem

Hi mamonetti,

Sorry to hear about this issue.
Please share your build configuration (configuration.h/user_settings.h), and your target platform.  Please also confirm if you are registering any CA certificates, and if so which function you are using.

Thanks,
Kareem

Hi Frederik,

When using a post-quantum algorithm, only the client needs to do keygen, as opposed to both sides for typical algorithms.  This explicit call helps us enforce this, and prevent doing keygen on the server-side.
In addition, having keygen in its own call allows us to speed up connection time by doing more work during initialization.
Since some post-quantum algorithms such as Kyber have multiple levels, our current approach also lets us prevent generating and sending excess keys for all levels, when only one level was requested.

Thanks,
Kareem