Great, can you please double check that the wolfssl.dll that is being linked with the application was generated using the same configuration headers that you are including with the application?

252

(6 replies, posted in wolfSSL)

Hi Scott,

Does the source file include `wolfssl/wolfcrypt/settings.h`?

Does the wolfssl DLL get created? Do the wolfSSL examples build correctly?

254

(2 replies, posted in wolfSSL)

Hi Chris,

I'll ask the team to review this for you...

Hello Ashwini,

The VS project uses the user_settings.h from the IDE/WIN folder by default:
https://github.com/wolfSSL/wolfssl/blob … settings.h

Your application should be including the following headers

#include <wolfssl/wolfcrypt/settings.h>

#include <wolfssl/ssl.h>

Please share the user_settings.h file that is being used.

Hello Ashwini,

Could you please confirm that the application is including the same options.h header (or settings.h, if using the user_settings.h method)?

Also please share your configuration and the actual error as printed from the linker.

Thanks,
Eric @ wolfSSL Support

257

(5 replies, posted in wolfSSH)

wolfSSH does not currently support FreeRTOS. If you are interested in opening a feature request to have us add support, please send an email to facts @ wolfssl.com

I can't recall if the platform you are using is able to produce debug logs. If so, that could help us determine what is happening when the crash occurs.

Another tool to help determine the stability of wolfSSL is to run the wolfCrypt test application:
https://github.com/wolfSSL/wolfssl/tree … crypt/test

This sounds like insufficient stack space. The 4096 RSA math uses a lot of stack memory! Have you tested using with the RSA_LOW_MEM option configured?

260

(5 replies, posted in wolfSSH)

Hi yass007

Certainly it is possible, just not currently implemented. You would need to add functionality for all the operations in order for standardized clients to connect properly. Alternatively, you could integrate a ramdisk that already has filesystem support.

261

(4 replies, posted in wolfSSL)

Hi Scott,

From the webpage you linked...

define the preprocessor macro “WOLFSSL_USER_SETTINGS” in your project

So in the project file that builds the wolfSSL library code, you should add a preprocessor macro for WOLFSSL_USER_SETTINGS. I clarify because you stated

define WOLFSSL_USER_SETTINGS in the APPLCATION...

The settings.h header will include user_settings.h, and those values will override anything in settings.h.

262

(4 replies, posted in wolfSSL)

Hello Scotty

The wolfSSL configuration is used to enable / disable support for features (including cipher suites) of the library. In the Win VS build, the configuration is handled by this file:
https://github.com/wolfSSL/wolfssl/blob … settings.h

Are you using a user_settings.h for the embedded system?

When building for embedded devices the best way to configure the wolfSSL library is to create a header named `user_settings.h`. Then at the global level in your application define `WOLFSSL_USER_SETTINGS` (or `./configure --enable-usersettings`) so that when `<wolfssl/wolfcrypt/settings.h>` is included throughout the library the `user_settings.h` header is also pulled in. The application should include `<wolfssl/wolfcrypt/settings.h>`, BEFORE all other wolfSSL headers. A good example `user_settings.h` for getting started on an embedded project can be found in:
https://github.com/wolfSSL/wolfssl/blob … settings.h
That example is well commented and provides a good starting point for any embedded project, even non-ARM based ones!

EDIT: Thanks, David, for answering!

Hello Chris,

I've asked Sean to review this post.

Thanks,
Eric @ wolfSSL Support

264

(1 replies, posted in wolfSSL)

Hi brunomarcoux

Please send an email to facts@wolfssl.com ands we can help you get started.

Hello ddnr,

What curve are you specifying with wc_ecc_export_x963_ex()?
The API wc_ecc_import_x963() only supports the default curve for a key size.
That is, the import could be creating a key with the wrong curve.

The API wc_ecc_import_x963_ex() allows the caller to specify the curve ID.
The curve ID can be obtained by calling:

wc_ecc_get_curve_id_from_name("BRAINPOOLP160R1")

Thanks,
Eric @ wolfSSL Support

266

(1 replies, posted in wolfSSL)

Thanks for contacting wolfSSL Support. NIST is currently selecting the next round of post-quantum crypto algorithms:
https://csrc.nist.gov/Projects/post-qua … yptography

The existing NTRU integration will not be maintained. We are aware that the NTRU library we tested with is no longer available:
https://github.com/NTRUOpenSourceProject/ntru-crypto

wolfSSL is working on support for the successor to NTRU:
https://github.com/open-quantum-safe/liboqs

You are welcome to send an email to facts@wolfssl.com to request more information.

Kind regards,
Eric @ wolfSSL Support

You can use the verify callback to over ride the cert signing errors. The example I shared earlier will accomplish what you are trying to do.

Hi sapi01

Need to clarify a couple points from your post:

> When I try to connect to my wolfSSL server, I'm getting `-188` on `wolfSSL_connect()`

Is this error in the client? Both peers will need the self-signed cert. You are basically doing a shared secret when doing mutual authentication and using self-signed certs.

Alternatively you could write a verify callback to override the cert failures for particular servers.

https://github.com/wolfSSL/wolfssl-exam … back.c#L55

Thanks,
Eric @ wolfSSL Support

Hello yass007

Thanks for contacting wolfSSL Support. Are you calling `wolfSSH_shutdown` before attempting the reconnect?
https://github.com/wolfSSL/wolfssh/blob … nt.c#L1140

Thanks,
Eric @ wolfSSL Support

270

(2 replies, posted in wolfSSL)

Hello a940153,

The `SSL_VERIFY_CLIENT_ONCE` flag is regarded as unsafe and is ignored in wolfSSL. You can use session tickets to securely reconnect a peer.

Hmm. Does it need to be called once (as in during some init), or in every encrypt / decrypt routine? I'd like to ping David about this next week.

Hi Tammy,

This sounds very similar to the ST HAL issue described here:
https://community.st.com/s/question/0D5 … le-missing

Thanks,
Eric @ wolfSSL Support

273

(1 replies, posted in wolfCrypt)

Hi Hu,

Please try adding a define for `WOLFSSL_SP_4096` to enable the larger bit sizes.

Thanks,
Eric @ wolfSSL Support

274

(2 replies, posted in wolfMQTT)

Hello kackle123

The web doc is out date from the code. There are two API

int MqttClient_WaitMessage_ex(MqttClient *client, MqttObject* msg,
        int timeout_ms)
{
    return MqttClient_WaitType(client, msg, MQTT_PACKET_TYPE_ANY, 0,
        timeout_ms);
}
int MqttClient_WaitMessage(MqttClient *client, int timeout_ms)
{
    if (client == NULL)
        return MQTT_CODE_ERROR_BAD_ARG;
    return MqttClient_WaitMessage_ex(client, &client->msg, timeout_ms);
}

As you can see, `MqttClient_WaitMessage` does take 2 parameters.

Are you trying to read an incoming publish, whose topic you have already subscribed? You should try setting up a publish callback. Here is an example:
https://github.com/wolfSSL/wolfMQTT/blo … ient.c#L58

Thanks,
Eric @ wolfSSL Support

275

(3 replies, posted in wolfSSL)

Here is the patch for the code to get the test working:


 fips_test.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/fips_test.c b/fips_test.c
index 78008dc..21db828 100644
--- a/fips_test.c
+++ b/fips_test.c
@@ -809,6 +809,15 @@ static int ECDSA_PairwiseAgreeTest(int type, const char* msg)
         return ret;
     }
 
+#ifdef ECC_TIMING_RESISTANT
+    ret = wc_ecc_set_rng(&ecc, &rng);
+    if (ret != 0) {
+        wc_ecc_free(&ecc);
+        wc_FreeRng(&rng);
+        return ret;
+    }
+#endif
+
     switch (type) {
         case WC_SHA256 :
         {