Hi ravi.kumar,

To use the `TLS13-AES128-GCM-SHA256` cipher suite you must also enable AES GCM. Please try adding `--enable-aesgcm` to your ./configure options.

Another helpful tip is you can get a list of available cipher suites using:
./examples/client/client -e

You can get a list of ./configure commands using `./configure --help`.

Thanks,
David Garske, wolfSSL

Hi Cxdinter,

Most AES mode require the input to be multiples of block size (16 bytes). TLS handles padding for block size. You should be able to pad with zeros if you want as long as the input is a multiple of 16 bytes. The resulting output will be the same length as the input. The decrypted text on the other side will have the padding and be a multiple of the block size. Most padding scheme use a length and known pad character. If you want to use AES and not worry about padding, I'd recommend AES GCM, which is an authentication cipher (wc_AesGcmEncrypt / wc_AesGcmDecrypt) and allows for any size input.

Thanks,
David Garske, wolfSSL

Hi bthoms01,

Usually this error means there was an issue placing network bytes into the read buffer.

You have `MQX_USE_IO_OLD` defined which causes the wolfio.c to use the old MQX RTCS. You might try adding some debug in the IO and doing a Wireshark trace.

Another option is to enable and set IO callbacks where you can handle the socket read/writes directly. To do this define `WOLFSSL_USER_IO` and set IO callbacks using:
WOLFSSL_API void wolfSSL_SetIORecv(WOLFSSL_CTX *ctx, CallbackIORecv CBIORecv);
WOLFSSL_API void wolfSSL_SetIOSend(WOLFSSL_CTX *ctx, CallbackIOSend CBIOSend);

You can find an example for this here:
https://github.com/wolfSSL/wolfssl-exam … ack.c#L194

If you don't require support for pre TLS 1.2 I'd recommend adding `NO_OLD_TLS`.

Let me know if that information is helpful or if you have any other questions.

Thanks,
David Garske, wolfSSL

Hi Ravi,

The ECC algorithm is only on by default wit the `x86_64` platform. Please try using `./configure --enable-ecc --enable-tls13`. If that doesn't work can you provide the wolfSSL version (or Git commit #) along with which platform you are building on?

Thanks,
David Garske, wolfSS

Hi Eyal,

That's wonderful! Very happy you got it all working.
Let me know if you have any other questions or issues.

Cheers,
David Garske

Hi Eyal,

I'm happy to hear you got it working!

The `-----BEGIN EC PARAMETERS-----\nBggqhkjOPQMBBw==\n-----END EC PARAMETERS-----` part is static. Meaning for a prime256v1 256-bit key its always the same and you can always pre-pend it to the generated key if its required. This is just a base 64 encoded ASN1 object id, which indicates prime256v1. I've added this to our feature request list. It would be good for us to have the ability to generate these ECC parameters.

The default curve type is the NIST prime curves, so when calling wc_ecc_make_key with 32 you get a NIST prime256v1 curve. If you use the wc_ecc_make_key_ex function you can provide a curve_id such as `ECC_SECP256R1`.

You can see all the ECC build options here:
https://github.com/wolfSSL/wolfssl/blob … /ecc.c#L32

You can see a list of all supported curves here:
https://github.com/wolfSSL/wolfssl/blob … ecc.c#L456

If you would like to save code space you can define `ECC_USER_CURVES`, which allows you to define specific curve sizes manually using the 'HAVE_ECC###`defines (256-bit is on by default).

Thanks,
David Garske, wolfSSL

Hi Eyal,

Thanks for evaluating wolfSSL! We have many customers using the STM32F4 with FreeRTOS. That is a great question!

To generate an ECC key:
1.  Make sure you have the `HAVE_ECC` defined.
2. Call:

ecc_key eccKey;
wc_ecc_make_key(rng, keySize, & eccKey);

Example: https://github.com/wolfSSL/wolfssl/blob … t.c#L11231

To create a CSR based on this ECC key:
1. Make sure you have `WOLFSSL_CERT_GEN` and `WOLFSSL_CERT_REQ` defined.
2. Call:

Cert req;
wc_MakeCertReq(&req, der, derSz, NULL, &eccKey);

Example: https://github.com/wolfSSL/wolfssl/blob … st.c#L8953

For an embedded system I find it best to put all my build options into a `user_settings.h` file (somewhere in your include path) and define `WOLFSSL_USER_SETTINGS`. You can find a good example for this here:

https://github.com/wolfSSL/wolfssl/blob … settings.h

Let me know if you have any issues or further questions.

Thanks,
David Garske, wolfSSL

Hi Brad,

I would agree with it being a stack size issue, but if you've increased it to 132KB that would be more than required. Depending on the configuration a typical stack use for a TLS session is about 15 KB.

Its possible there is a BIG ENDIAN issue, but we continuously test with little and big endian, so I don't think that's the problem.

There are a couple of defines you can try using that might help:

#define ECC_TIMING_RESISTANT
#define NO_64BIT

The NO_64BIT could help if your compiler is having issue with the long long type. The ECC timing resistance uses a different math computation that is slower, but uses less stack.

Also you can limit the ECC curve size for by using `#define ECC_USER_CURVES`. This will enable only 256-bit curves by default and you can use defines like `HAVE_ECC384` to enable other curve sizes.

Here is an ECC section of a `user_settings.h`, which might be helpful:
https://github.com/wolfSSL/wolfssl/blob … ings.h#L48

Let me know if this helps or if you have any other questions.

Thanks,
David Garske, wolfSSL

Hi Nimesh,

It sounds like you've already got past the most difficult part which is getting TLS running. Adding wolfMQTT on top is quite simple. You can download the latest source code for wolfMQTT v0.13 here:
https://github.com/wolfSSL/wolfMQTT

We have an example for using AWS in the 'examples/aws/awsiot.c` file. To enable TLS support build with the define `ENABLE_MQTT_TLS` set. You may need to change the `examples/mqttnet.c` to use TI-RTOS compatible network calls.

Let me know if you have any issues or questions.

Thanks,
David Garske, wolfSSL

Hi Gussabina,

That explains the issue you are seeing. The protection needs to happen at the MQTT protocol level since MQTT does not provide a way to split up publish messages. There is a header and the message follows behind which may span over multiple TLS / TCP packets. Additionally the publish being sent can respond with a confirmation if using Qos of 1 or 2.

So the answer is you will need to implement a way to make sure each thread has exclusive access to the MQTT library. I'd recommend either have single thread and using FreeRTOS queue to pass between threads or adding mutex protection around both MQTT tasks and implement non-blocking MQTT mode so it does not block and each thread gets access to the socket.

Thanks,
David Garske, wolfSSL

Hi Gus,

Typically if things break-down after the connection has already been running fine indicates to me some memory issue either with corruption or memory leak. I recommend adding some memory checking to measure heap use and also stack use. We have some hooks for monitoring heap that can be enabled using `WOLFSSL_TRACK_MEMORY`. This will add tracking on XMALLOC/XFREE and display a result on wolfSSL_Cleanup() or `ShowMemoryTracker()`. Measuring stack is typically RTOS specific. What OS / Micro-controller are you using? Are you using any hardware crypto acceleration?

A typical recovery for a connection error would be to call `wolfSSL_shutdown(ssl)`, `wolfSSL_free(ssl)` and `close()` the socket. This will cleanup everything and allow you to reconnect again just as you did before. If you are having a memory issue I suspect you'll see problems reconnecting as well. We have a collection of TLS examples here: https://github.com/wolfSSL/wolfssl-exam … master/tls

Thanks,
David Garske, wolfSSL