201

(1 replies, posted in wolfSSL)

Hi torntrousers,

The wolfMQTT AWS example is located here:
https://github.com/wolfSSL/wolfmqtt#azu … ub-example
https://github.com/wolfSSL/wolfMQTT/tre … ples/azure

The latest work for the RA6M3 is here:
https://github.com/wolfSSL/wolfssl/tree … udio/RA6M3
We also have a PR that adds hardware crypto support here:
https://github.com/wolfSSL/wolfssl/pull/2835

The SCE support is outdated and is being worked on this week. If you would like to find out more please email support@wolfssl.com and tell us a bit more about your project.

Thanks,
David Garske, wolfSSL

202

(6 replies, posted in wolfSSL)

Hi windyMk92,

You might also want to use these API's to set your own IO callback context pointer. This will allow you to specify a different socket/IO context for each thread.

wolfSSL_SetIOReadCtx
wolfSSL_SetIOWriteCtx

Thanks,
David Garske, wolfSSL

203

(6 replies, posted in wolfSSL)

Hi windyMk92,

The attachments are missing. Feel free to email support@wolfssl.com if you cannot post them here.

Is the issue specific to two concurrent threads or just when the STM32F7 is acting as the server? Are you using AES Hardware acceleration? If so have you tried disabling using NO_STM32_CRYPTO?

For multi-threading the common issues are not using mutex protection on the WOLFSSL object between threads. For the WOLFSSL_CTX you should have separate ones. Make sure the server side CTX constructor is using the wolfTLSv1_2_server_method or wolfSSLv23_server_method (to select highest available TLS version and allow downgrade).

We have some excellent TLS examples here: https://github.com/wolfSSL/wolfssl-exam … master/tls

Thanks,
David Garske, wolfSSL

Hi Andreas,

Can you please try updating to the latest wolfSSL GitHub master? There are fixes in since v4.5.0 in aes.c for these STM32 functions.

The latest STM32 Cube MX HAL version I can find is v1.8. I ran our TLS cipher suite test on the H753ZI board with AES crypto hardware acceleration enabled and could not reproduce an issue.

Here is the example I am using:
https://drive.google.com/file/d/1-RIGxq … sp=sharing

Thanks,
David Garske, wolfSSL

Hi Andreas,

I understand, one is using our wolfCrypt software to calculate the AES GCM HMAC. The other is using the STM hardware. Are you able to printout/capture the following variables in the failure case  "sz", "ivSz", "authTagSz" and "authInSz?

What is the version of the STM32 Cube MX Hal code you are using?

Thanks,
David Garske, wolfSSL

Hi AnMu5962,

The issue appears to be related to the AES GCM auth tag calculation. There are fixes for this and this has been tested recently.

Can you confirm you are using the latest wolfSSL master and the latest STM32 Cube MX pack for the H7? Are you using the `STM32_HAL_V2` build option?

If you are using the latest can you print out the "sz", "ivSz", "authTagSz" and "authInSz" being used?

Thanks,
David Garske, wolfSSL

Hi Nevilshute,

It sounds like you were able to resolve it by enabling the Hash security peripheral in the Cube MX tool? Let me know if you have any other issues or questions.

Thanks,
David Garske, wolfSSL

208

(7 replies, posted in wolfCrypt)

Hi Vitus,

I see your bug. In the sign.c see this line `if ((ret = wc_ecc_sign_hash(hash, sizeof(hash), signature, signature_size, &rng, &key)) != 0)`. You are using `sizeof(hash)` and it should be `hash_size`.

Thanks,
David Garske, wolfSSL

209

(7 replies, posted in wolfCrypt)

Hi Vitus,

The last argument to `wc_EccPublicKeyToDer` is "with_AlgCurve" is a flag for when to include a header that has the Algorithm and Curve information". You should have it set to 1. Also you are not checking the return code from wc_EccPublicKeyDecode in the "verify" function.

You might find the wolfcrypt/test/test.c examples for `crypto_ecc_verify` and `crypto_ecc_sign` helpful. Those are around line 21646.

Thanks,
David Garske, wolfSSL

210

(1 replies, posted in wolfSSL)

Hi sean00mcc,

You need to include the "-lm" for the std math library or use internal DH math using `WOLFSSL_DH_CONST`.

Thanks,
David Garske, wolfSSL

211

(1 replies, posted in wolfSSL)

Hi buoy,

I am not aware of any Microblaze cross compile efforts.

Try something like this:

./configure --host=aarch64 CC=mb-g++ --disable-filesystem --disable-shared --disable-examples --disable-crypttests --prefix=[installdir]
make
make install

We have a few Xilinx examples located here:
https://github.com/wolfSSL/wolfssl-examples/pull/155
https://github.com/wolfSSL/wolfssl/tree … /XilinxSDK


Thanks,
David Garske, wolfSSL

Hi Scotty2541,

The manual is wrong/out of date. If WOLFSSL_TLS13 (--enable-tls13) is set then `wolfSSLv23_server_method` will try TLS v1.3 first and allow downgrade. If you want to disable SSLv3 and TLS 1.0 then make sure these are not defined `WOLFSSL_ALLOW_TLSV10` and `WOLFSSL_ALLOW_SSLV3`.

Thanks,
David Garske, wolfSSL

Hi Petr,

Thanks for the report and I suspect you are correct about this issue. I will investigate and provide some feedback shortly.

Thanks,
David Garske, wolfSSL

214

(9 replies, posted in wolfSSL)

Hi vysocan76,

It looks like you are using the Standard Peripheral Library, which means you would not define WOLFSSL_STM32_CUBEMX. You might consider switching to the Cube HAL, which is still supported by ST. The SPL is end of life.

Thanks,
David Garske, wolfSSL

215

(9 replies, posted in wolfSSL)

Hi vysocan76,

You might try adding `STM32_HAL_V2` to see if that will help.

Also you might try adding SP ECC support (WOLFSSL_HAVE_SP_ECC). If you are using ECDHE it will improve handshake time.

Can you tell me what cipher suite TLS is using?

If you are using USE_FAST_MATH with TFM_ARM that will be faster than normal math. And the SP WOLFSSL_SP_ARM_CORTEX_M_ASM is several times faster than that.

There is a good article https://www.wolfssl.com/user-generated- … wlib-nano/ that might help.

Thanks,
David Garske, wolfSSL

216

(9 replies, posted in wolfSSL)

Hi vysocan76,

When you updated to the latest wolfSSL release did you pull latest master?

There have been some STM32 fixes after v4.5.0 here:
https://github.com/wolfSSL/wolfssl/pull/2996
https://github.com/wolfSSL/wolfssl/pull/3169

This error "AES_GCM_AUTH_E     = -180,  /* AES-GCM Authentication check failure */" is resolved with those PR's.

For the second issue with DH performance.... Those are complex math operations. You have three options.
1. Normal math (interger.c) don't define USE_FAST_MATH. This uses heap and is the smallest and slowest.
2. Use Fast math (tfm.c) define USE_FAST_MATH. This uses stack and is slightly faster.
3. Use Single Precision (sp_int.c) math. Define WOLFSSL_SP_DH. If you want to leverage CortexM speedups also define WOLFSSL_SP_ARM_CORTEX_M_ASM and it will use the sp_cortexm.c which is your fastest option.

SP build options are documented in the code here:
https://github.com/wolfSSL/wolfssl/blob … _int.c#L42

Thanks,
David Garske, wolfSSL

Hi ykuz,

It would help if you could point me to or share your code with me.

Make sure your header includes "#include <wolfssl/wolfcrypt/types.h>" which includes visibility.h. Take a look at wolfssl/wolfcrypt/visilbility.h and make sure you define BUILDING_WOLFSSL and HAVE_VISIBILITY.

Thanks,
David Garske, wolfSSL

Hi ykuz,

Make sure you add "WOLFSSL_API" to the header definition of the API, so it is available. Let me know if that doesn't help.

Thanks,
David Garske, wolfSSL

Hi wnqu,

Please make sure you include <wolfssl/options.h> prior to any other wolfSSL headers in your application. I am guessing that will resolve this. If not make sure you change the link to "-lwolfssl".

Thanks,
David Garske, wolfSSL

220

(1 replies, posted in wolfSSL)

Hi Scotty2541,

There are a few types of session resumption.
1. Session cache on the server side, client uses a session id to determine which resumption. This requires server to store / cache session information.
2. Session tickets where server encrypts blob that client retains and presents it in the TLS session ticket extension. This one uses no resources on the TLS server.

For session ID its on by default unless "NO_SESSION_CACHE" is set. To use it here is an example.

/* Do TLS connect, read and write. */
/* Before shutdown or socket close call... */
WOLFSSL_SESSION* session = wolfSSL_get_session(ssl);

/* On next connect set the session before the TLS connect (wolfSSL_connect). */
wolfSSL_set_session(ssl, session);

For Session Tickets you must enable and optionally set a callback:

static int sessionTicketCB(WOLFSSL* ssl,
                    const unsigned char* ticket, int ticketSz,
                    void* ctx)
{
    (void)ssl;
    (void)ticket;
    printf("Session Ticket CB: ticketSz = %d, ctx = %s\n", ticketSz, (char*)ctx);
    return 0;
}

wolfSSL_UseSessionTicket(ssl);
wolfSSL_set_SessionTicket_cb(ssl, sessionTicketCB, (void*)"initial session");

Here is an example for TLS client resumption:
https://github.com/wolfSSL/wolfssl-exam … s-resume.c

Thanks,
David Garske, wolfSSL

Hi AnMu5962,

Try adding "--disable-filesystem" to disable support for the file system. Cross compiling for a ARM armv7e with arm-none-eabi does not include STDIO file system support.

Thanks,
David Garske, wolfSSL

Hi Octopus01,

After the call to `wc_InitCert` you need to set subject, serial number, sigType and key usage for "keyCertSign". See example here: https://github.com/wolfSSL/wolfssl/blob … t.c#L12504

If you are using a self-signed certificate for the client mutual authentication then the server side needs to load this same certificate using `wolfSSL_CTX_load_verify_buffer`.

Thanks,
David Garske, wolfSSL

Hi Octopus01,

We have some good TLS examples here:
https://github.com/wolfSSL/wolfssl-exam … master/tls

The certificate is missing all the subject information (like common name). I suspect this certificate does not meet the requirements for TLS mutual auth. How did you generate this certificate?

Thanks,
David Garske, wolfSSL

Hi Octopus01,

Perhaps double check the use of `wolfSSL_CTX_trust_peer_buffer` on the client side. You should be using `wolfSSL_CTX_load_verify_buffer`. The -155 (ASN_NO_SIGNER_E) indicates the provided peer (server in this case) certificate could not be verified. If you want to bypass that check most users alter the `wolfSSL_set_verify` API call to use `WOLFSSL_VERIFY_NONE`, however this will bypass all peer certificate checking, so use it with caution.

Thanks,
David Garske, wolfSSL

225

(2 replies, posted in wolfCrypt)

Hi RyVel,

My first guess is a FIPS boundary check hash issue. If HAVE_FIPS (--enable-fips=v2) is set you must update the fips boundary hash in fips_test.c. See https://www.wolfssl.com/docs/fips-ready-user-guide/

Using a test seed won't cause this error, however a failure with the DRBG such as SHA256 returning FIPS_NOT_ALLOWED_E would.

Please review the FIPS ready user guide and let us know if that doesn't resolve it.

Thanks,
David Garske, wolfSSL