Hi Tammy,

Are you using the Cube MX HAL? If so what version? The Cube HAL handles enabling the clock automatically with the generated code.

If you still need to manually control the peripheral clock for power consumption reasons you can do it with the following:

The __HAL_RCC_AES_CLK_ENABLE() API comes from stm32l4xx_hal_rcc.h which gets included via stm32l4xx_hal_conf.h if the HAL has been generated with HAL_CRYP_MODULE_ENABLED set.

Which L4 part are you using and what wolfSSL build options have you defined in the user_settings.h or wolfSSL.wolfSSL_conf.h?

Thanks,
David Garske, wolfSSL

Hi mahdyseifelnasr,

We fully support the CortexM0 with some impressive assembly speedups for ECC, RSA and DH.

There is a good Makefile template for GCC ARM here:
https://github.com/wolfSSL/wolfssl/tree … DE/GCC-ARM

If you would prefer to cross-compile using ./configure here is an example:
./configure --host=arm-none-eabi CC=gcc AR=ar --disable-shared --enable-cryptonly --disable-examples --disable-crypttests --prefix=[yourpath]

If you have the option to use the STM32Cube wolfSSL pack it allows you to generate code on many STM32 targets and IDE's.

Thanks,
David Garske, wolfSSL

Hi cxenof03,

That is correct. For TLS v1.3 you can use HAVE_SECRET_CALLBACK and wolfSSL_set_tls13_secret_cb to setup a callback for printing the secrets for use with Wireshark.

The WOLFSSL_STATIC_EPHEMERAL feature does allow you to use a fixed ephemeral key for testing, which can be loaded into Wireshark. The WOLFSSL_STATIC_EPHEMERAL is meant to be used with the WOLFSSL sniffer (--enable-sniffer) and sslSniffer/sslSnifferTest, which allows decryption of the TLS traffic.

If you'd like some additional documentation on this please email us directly using support@wolfssl.com.

Thanks,
David Garske, wolfSSL

Hi Iyaps,

You can do either ./configure with cross compile or a Vitis IDE project.

We have a full example project here:
https://github.com/dgarske/UltraZed-EG-wolf

For cross-compiling here is an example I used for QNX on the ZCU102:

./configure --host=aarch64 \
    CC="aarch64-unknown-nto-qnx7.0.0-gcc" \
    AR="aarch64-unknown-nto-qnx7.0.0-ar" \
    RANLIB="aarch64-unknown-nto-qnx7.0.0-ranlib" \
    --prefix=$WOLFSSL_BUILD_DIR \
    --disable-shared --disable-examples --disable-crypttests \
    CFLAGS="-DWOLFSSL_HAVE_MIN -DWOLFSSL_HAVE_MAX \
    -DFP_MAX_BITS=8192" --enable-fastmath \
    --enable-armasm --enable-sp --enable-sp-asm

With some minor adjustments to the compile CC you could build with a generic GCC like "aarch64-none-elf-". You might also need to add CFLAGS= "-march=armv8-a"

Thanks,
David Garske, woilfSSL

Hi Iyaps,

Have you called wolfSSL_Init() or wolfCrypt_Init() in your application code?
In your Xilinx BSP / Hardware Platform have you enable the xilsecure library?
Have you seen our Xilinx FreeRTOS/LWIP example here:
https://github.com/wolfSSL/wolfssl-examples/pull/155
https://github.com/JacobBarthelmeh/wolf … x/FreeRTOS

We also have some Xilinx tips here:
https://github.com/wolfSSL/wolfssl/tree … /XilinxSDK

Thanks,
David Garske, wolfSSL

Hi Abhishek,

I can reproduce and have an updated pack posted here:
https://drive.google.com/file/d/1WWGrJb … sp=sharing

You can manually exclude the folder, but as a solution I've removed it from the pack.

It will be on the website shortly at the linked location:
https://www.wolfssl.com/files/ide/I-CUBE-wolfSSL.pack

Thanks for the report.
David Garske, wolfSSL

Hi Remy,

Is it possible you need to call `int wc_ecc_make_pub_ex(ecc_key* key, ecc_point* pubOut, WC_RNG* rng)` first to generate the public key material?

I've also asked our PKCS11 expert Sean P to review this post.

Thanks,
David Garske, wolfSSL

Hi Abhishek,

The files in linuxkm should be excluded from your project. That folder exclusion change has already been made to the pack. Please update to the v4.7.0 version of the pack.

https://www.wolfssl.com/files/ide/I-CUBE-wolfSSL.pack

Thanks,
David Garske, wolfSSL

Hi Kim,

I don't see `#define FP_MAX_BITS 8192`? Also consider having DH 4096-bit support by adding `#define HAVE_FFDHE_4096`.

For manually adding build options with ./configure use the syntax:
`./configure CFLAGS="-DFP_MAX_BITS=8192 -DHAVE_FFDHE_4096"`
Of course adding your "--enable-[options]" to this as well.

Thanks,
David Garske, wolfSSL

Hi Kim,

Can you share details for how you are building wolfSSL? Are you cross-compiling for QNX using ./configure CC= or using QNX Momentics directly?

It is important that your build settings for the wolfSSL library and your application match. If using ./configure there is a generated wolfssl/options.h file that needs to get included in your application prior to any other wolfSSL headers. If you are building the wolfSSL sources directly configuration is usually done through your own file "user_settings.h" and a pre-processor macro "WOLFSSL_USER_SETTINGS". We have many templates for user_settings.h in examples/configs.

For me building for that target here are some steps I use:

cd ~
source qnx700/qnxsdp-env.sh

# Destination for static library and includes
mkdir wolfssl_build_qnx
export WOLFSSL_BUILD_DIR=`pwd`/wolfssl_build_qnx

git clone https://github.com/wolfSSL/wolfssl.git
cd wolfssl

./autogen.sh
./configure --host=aarch64 \
    CC="aarch64-unknown-nto-qnx7.0.0-gcc" \
    AR="aarch64-unknown-nto-qnx7.0.0-ar" \
    RANLIB="aarch64-unknown-nto-qnx7.0.0-ranlib" \
    --prefix=$WOLFSSL_BUILD_DIR \
    --disable-shared --disable-examples --disable-crypttests \
    CFLAGS="-DWOLFSSL_HAVE_MIN -DWOLFSSL_HAVE_MAX \
    -DFP_MAX_BITS=8192" --enable-fastmath \
    --enable-armasm --enable-sp --enable-sp-asm

make
make install

Notes:
•    The "source" sets up environment variables that QNX expects.
•    The configure is used to cross-compile wolfSSL as a static library for QNX.
•    The output is a wolfSSL static library and headers in "wolfssl_build_qnx".
•    The “wolfssl/options.h” is generated by ./configure and must be included prior to any other wolf headers in your application.
•    The “—enable-armasm” option enables the aarch64 assembly speedups.
•    The “--enable-sp” and “--enable-sp-asm” options enable the optimized RSA/DH/ECC math.
•    The FP_MAX_BITS=8192 allows 4096-bit keys.

Thanks,
David Garske, wolfSSL

Hi Abhishek,

1) Yes we are compatible, but each part has slight variations, such as if it supports crypto hardware. The goal is for you to add your own section or use this file as a template to implement your own build settings by coping this file and naming it user_settings.h and adding the pre-processor build macro WOLFSSL_USER_SETTINGS. If you add your own section in config.ftl that is generic feel free to submit here and we can include in the next wolfSSL release cube pack.

2) wolfSSL and wolfCrypt can be used without an OS in bare-metal. The example applications for TLS requires threading because it uses two threads to exchange data as an example. The cube pack code can be generated without an RTOS, but you won't be able to use the TLS example. You can still use TLS in your application code.

Thanks,
David Garske, wolfSSL