(3 replies, posted in wolfMQTT)

Hi Davide,

This is a bit more complex problem than what should be supported in a forum post. Could you please open a formal support ticket by emailing support@wolfssl.com?



(1 replies, posted in wolfSSL (formerly CyaSSL))

Hello lili,

Thanks for your post. PSK is used to negotiate the first connection handshake. If sessions are enabled, the server will provide a session key (or ticket) that can be to quickly resume the connection without the full handshake.

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

Kind regards,
Eric @ wolfSSL Support


(1 replies, posted in wolfSSL (formerly CyaSSL))

Hello zyhaha,

Thanks for joining the wolfSSL Forums. It sounds like the server is expecting the client to use a session ticket to renegotiate the connection. Could you please share a pcap of the first and second connections?

Kind regards,
Eric @ wolfSSL Support

Hello Ahmed,

Thanks for also emailing wolfSSL support. I've responded to your questions from our ZenDesk portal.

Kind regards,
Eric @ wolfSSL Support


(1 replies, posted in wolfCrypt)

Hello cachristiansen

Thanks for joining the forum. In order to provide highest priority support, we recommend emailing support@wolfssl.com with your questions.

The default implementation of wc_RNG_GenerateBlock will use the TSIP RNG via the seed operation. You can implement you r own block RNG function by defining CUSTOM_RAND_GENERATE_BLOCK.

Eric @ wolfSSL Support


(3 replies, posted in wolfMQTT)

Hello Davide,

Thanks for joining the wolfSSL forums. The timeout error simply indicates that the client has been inactive long enough that it needs to send a ping to the broker to maintain the connection. It is an informative error.

Could you tell us more about your project and goals with wolfMQTT?

Eric @ wolfSSL Support

Hello Malik,

Thanks for joining the wolfSSL Forums.

The -322 code corresponds to the following error in wolfssl/error-ssl.h

    DOMAIN_NAME_MISMATCH         = -322,   /* peer subject name mismatch */

The error code DOMAIN_NAME_MISMATCH would make sense if you are using a certificate issued for one domain with a different domain.

Could you please provide some more details such as the domains in question, the cert(s) in question and how we might reproduce on our end?

Do you have a site accessible that we can test against and a copy of the certificate in question?

Kind regards,
Eric @ wolfSSL Support

Hi beaveryoga,

Excellent, thanks for sharing this! Were there any issues or changes required?

Kind regards,
Eric @ wolfSSL Support

Hello celov65111

Welcome and thanks for joining the wolfSSL Forums. I moved this topic to the wolfTPM section, under the assumption that you are using wolfTPM to access the TPM device. Please correct me if I am mistaken.

Here is an example of reading a key from nvram:
https://github.com/wolfSSL/wolfTPM/blob … ram/read.c

Let us know if there are any questions.

Kind regards,
Eric @ wolfSSL Support

Hi labonte_d

Thanks for contacting wolfSSL Support. The compatibility layer of wolfSSL is intended to cover the most widely used OpenSSL API, but there are some gaps. I can open open a feature request for implementing the BIO_TYPE_SOCKET type if you'd like. I'd suggest adding the type define and seeing if there are further issues.

For the SHA224_Init issues, I do see that SHA224_Init is defined to wolfSSL_SHA224_Init in wolfssl/wolfssl/openssl/sha.h

Does realm-core/src/realm/util/encrypted_file_mapping.cpp include options.h before any other wolfSSL headers?

Eric @ wolfSSL Support


(1 replies, posted in wolfSSL (formerly CyaSSL))

Hello Manaury,

We have an excellent PKCS12 example that parses out the key and cert:
https://github.com/wolfSSL/wolfssl-exam … pto/pkcs12

(I replied to your support ticket, but I am copying the response here for posterity.)


(2 replies, posted in wolfMQTT)

Hello Rafa,

Welcome to the wolfSSL Forums. Yes, you are absolutely on the right track. The network layer of wolfMQTT is transport agnostic. Here is an example of a UART port:
https://github.com/wolfSSL/wolfMQTT/blo … mqttuart.c

You'll notice the network layer only requires a structure and a few functions.

Let us know if there are questions and feel free to email support@wolfssl.com for priority pre-sales support.

Eric @ wolfSSL Support

>  lws cannot find wolfSSL_X509_VERIFY_PARAM_set1_host

This is quite odd. The macro `OPENSSL_EXTRA` is the only define gating the definition. Maybe try with


instead of using the CFLAG value.

Hi r-type,

Yes, you can modify the CMakeLists.txt. Our CMake build is a work-in-progress. Alternatively, you can also pass in wolfSSL build options like this:



(2 replies, posted in wolfSSL (formerly CyaSSL))

Hi Angelo,

We do have some newer documentation that is prerelease. I can share this with you if you can send a request to support@wolfssl.com


(2 replies, posted in wolfSSL (formerly CyaSSL))

Hello Angelo,

Thanks for joining the wolfSSL Support Forum. I know the CAAM driver has to be specially built and linked in order for wolfSSL to access the driver. Please see the instructions here:
https://github.com/wolfSSL/wolfssl/blob … am_doc.pdf

I will check about the intended usage of the configure option `--enable-caam`

Eric @ wolfSSL Support

Hello Jerry,

Thanks for joining the forums. For the version of FIPS Ready you are building, you'll want to change the versions to:


I'd invite you to send an email to support@wolfssl.com in order to better prioritize questions.

Eric @ wolfSSL Support

Hello eMKa94

Thanks for joining the forums. Here is a link to our porting guide:

You can specify the build environment using the config command:


./configure \
CC="/path/to/your/toolchain/toolchain-gcc" \
AR="/path/to/your/toolchain/toolchain-ar" \
AS="/path/to/your/toolchain/toolchain-gcc" \
RANLIB="/path/to/your/toolchain/toolchain-ranlib" \
LD="/path/to/your/toolchain/toolchain-ld" \
--host=<your host> \
<your other configure options here> \
CFLAGS="-mcpu=<your cpu definition here> \
<other cflags here>" \


./configure \
CC="/usr/local/gcc_arm/gcc-arm-none-eabi-7-2017-q4-major/bin/arm-none-eabi-gcc" \
AR="/usr/local/gcc_arm/gcc-arm-none-eabi-7-2017-q4-major/bin/arm-none-eabi-ar" \
AS="/usr/local/gcc_arm/gcc-arm-none-eabi-7-2017-q4-major/bin/arm-none-eabi-gcc" \
RANLIB="/usr/local/gcc_arm/gcc-arm-none-eabi-7-2017-q4-major/bin/arm-none-eabi-ranlib" \
LD="/usr/local/gcc_arm/gcc-arm-none-eabi-7-2017-q4-major/bin/arm-none-eabi-ld" \
--host=arm-none-eabi \
--enable-aesgcm --enable-ecc \
CFLAGS="-mcpu=cortex-m4 \
-Os -specs=rdimon.specs"  \
LIBS="-Wl,--start-group -lm -lgcc -lc -lrdimon -Wl,--end-group"

Let us know if there are questions.

Eric @ wolfSSL Support

It is possible to optimize, but we have not yet implemented the needed support on this platform. You are welcome to formally request this feature.

Also can you suggest any tips, best practices or parallelization techniques to improve decryption performance with the current wolfcrypt release (5.2.0). is there any way I can improve performance, at software level.

We have several math library optimizations that you can try. Here is an example config:
https://github.com/wolfSSL/wolfssl/blob … template.h
I recommend testing with WOLFSSL_SP_MATH and WOLFSSL_SP_MATH_ALL

]Currently my application is showing 25-30% cpu usage without decryption and with decryption it shows 60-70% cpu usage, is this normal?

Without HW acceleration enabled, this sounds plausible.

Hello Iycboy,

Thanks for joining the wolfSSL Forums. The public key is required for signing with ed25519:

https://datatracker.ietf.org/doc/html/r … tion-5.1.6

Construct the secret scalar s from the first half of the digest, and the corresponding public key A, as described in the previous section.

We have some excellent examples in a separate repository:
https://github.com/wolfSSL/wolfssl-exam … pk/ed25519

Let us know if there are questions.

Eric @ wolfSSL Support

My colleague reminded me that this should be clarified!

The library does not support optimization for AES CBC… We do support optimization for all asymmetric math operations.

Hi abdulwazeed1,

We do not currently support any optimizations for ARMv7. Would you like to open a feature request? Please send an email to support@wolfssl.com

Eric @ wolfSSL Support

Hello Lars,

That is an interesting use case. The library actually has a new ASN parser that can be enabled using

./configure --enable-asn=template

There are other options that can be enabled with the defines documented
in https://github.com/wolfSSL/wolfssl/blob … /src/asn.c

 * WOLFSSL_ASN_TEMPLATE: Encoding and decoding using a template.
 * WOLFSSL_DEBUG_ASN_TEMPLATE: Enables debugging output when using ASN.1
 * WOLFSSL_ASN_TEMPLATE_TYPE_CHECK: Use ASN functions to better test compiler
    type issues for testing
 * CRLDP_VALIDATE_DATA: For ASN template only, validates the reason data

Mostly the ASN1 handling in the library is in the context of certificate handling, but maybe you'll find this extension callback example useful:
https://github.com/wolfSSL/wolfssl-exam … callback.c

Let us know if there are questions.

Eric @ wolfSSL Support

I reviewed this with the team, and this may have been fixed since the v5.1.1 release. Could you please test with the revision master from https://github.com/wolfSSL/wolfssl ?

A new source file was added,


, and it is not being built by your VS project.

The VS project files in the repository have been updated in the latest release.