Hi harish,

Where did you download wolfSSL from? Did it come from: https://www.wolfssl.com/download/ or somewhere else?

Warm Regards,

KH

Hi @rafaelzingler,

Ahh so it must be coming from some other cert in the chain that uses SHA384 then. Yes can you try adding the settings:

WOLFSSL_SHA512
WOLFSSL_SHA384 // Truncated sha512 so you need sha512 enabled too!

OR

--enable-sha512 --enable-sha384

Let us know if that works.

Warm Regards,

KH

Hi rafaelzingler,

There is nothing wrong with your settings, the -188 error code means you just haven't loaded the right cert in to validate the peer you are connecting to!

The API wolfSSL_CTX_load_verify_buffer is most common on embedded devices unless you have a file system in which case you can use wolfSSL_CTX_load_verify_locations instead. You want to load the Root CA that signed the peer cert chain.

If you have any trouble finding the right cert to load please send us the IP of a public server we can connect to and we'd be happy to track down the right cert for you.

Warm Regards,

KH

Hi agoswam,

You indicated the digest size is 51 which may be the source of the issue. You are passing WC_HASH_TYPE_SHA256 which has a digest of only 32-bytes not 51.

A SHA256 digest is 32-bytes long,
A SHA384 digest is 48-bytes long,
and
A SHA512 digest is 64-bytes long.

There are no digests that are 51 bytes long. Can you double check the digest length?

Warm Regards,

K

Hi Oytis,

Thank you for reaching out with your question. As noted in the comment the valid use case for the callback function that can always return success is when you are using a Hardware Security Module to check the signature for you (ATECC508A/608A, ST Safe, etc). There is no need to check the signature twice, that just wastes computation cycles that could be spend on more interesting tasks.

The valid use case for checking the signature that was generated is if you wish to ensure the signature is valid before sending it. Imagine you have a backend system that can crank out thousands of signatures but you're sending those signatures to embedded systems that take on the order of 10's or 100's of seconds to perform a verify operation. You can save some time by checking the signatures are correct on the backend before shipping them to the field devices rather then sending a bad one, having the field device fail, and then sending another. Our library is designed with embedded systems in mind and we provide some unique functionality for those of our users that have requested it.

Please let us know if you have any other questions!

Warm Regards,

KH

Hi JMG,

Can you tell us a bit about the project and what/who is driving the effort?

To start please uncomment the define FREERTOS in wolfssl-root/wolfssl/wolfcrypt/settings.h and add the define WOLFCRYPT_ONLY to disable SSL/TLS functionality for just the crypto.

Please let us know if you encounter any issues as you get started!

Warm Regards,

K

@torntrousers,

On TLS 1.3, we recently posted a blog with the required settings to use for TLS 1.3 when not using ./configure to build, this was a blog for building on windows https://www.wolfssl.com/building-wolfss … 3-windows/

You can apply those same settings to user_settings.h in the arduino build!

#define WOLFSSL_TLS13
#define HAVE_TLS_EXTENSIONS
#define HAVE_SUPPORTED_CURVES
#define HAVE_ECC
#define HAVE_HKDF
#define HAVE_FFDHE_8192
#define WC_RSA_PSS

You noted the available heap was roughly 21k, how much stack was available? For an ECDHE_ECDSA you can usually get it down to about 12k stack, 16k heap for a handshake (varies slightly depending on number of certs in chain from the peer). Chapter 2 of the wolfSSL manual has a section for reducing resource usage https://www.wolfssl.com/documentation/w … Manual.pdf

Checkout Chapter 2 section 2.4.7 Reducing Memory Usage.

Let us know if you are able to get it working on the ESP8266 using some of the finer resource usage reduction settings!
If not those aren't enough try these also:

#define NO_RSA // Disable RSA entirely
// Assuming the setting USE_FAST_MATH is used for these next ones:
#define ECC_USER_CURVES // disable all curves except SECP256r1
#define FP_MAX_BITS 512 // Set to just large enough for 256-bit curves since no RSA is enabled.

Warm Regards,

KH

Anil,

Good deal! Happy to hear you identified the root cause. Let us know if anything else comes up!

- KH

NOTE: Being worked on via zendesk through support@wolfssl.com

PKLApps,

TLS 13 wasn't added until release 3.12.0 and at that time it was still in draft form. Please try testing with release 4.0.0 and let us know if you have any issues.

Warm Regards,

KH