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 Abhishek,

That is good news regarding the Cube pack.

We fully support both bare-metal and LWIP. For LWIP we support either the Posix or RAW interface. With the LWIP Posix interface requires threading (I believe). We do have an LWIP raw example in an old PR here:
https://github.com/wolfSSL/wolfssl/pull/599

Another option is to define `WOLFSSL_USER_IO` and set read / write callbacks using the following API's:

/* I/O callbacks */
typedef int (*CallbackIORecv)(WOLFSSL *ssl, char *buf, int sz, void *ctx);
typedef int (*CallbackIOSend)(WOLFSSL *ssl, char *buf, int sz, void *ctx);
WOLFSSL_API void wolfSSL_CTX_SetIORecv(WOLFSSL_CTX*, CallbackIORecv);
WOLFSSL_API void wolfSSL_CTX_SetIOSend(WOLFSSL_CTX*, CallbackIOSend);
WOLFSSL_API void wolfSSL_SSLSetIORecv(WOLFSSL*, CallbackIORecv);
WOLFSSL_API void wolfSSL_SSLSetIOSend(WOLFSSL*, CallbackIOSend);

We have some examples for this here:
https://github.com/wolfSSL/wolfssl-exam … callback.c

Thanks,
David Garske, wolfSSL

153

(3 replies, posted in 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

154

(4 replies, posted in wolfSSL)

Hi All,

I have posted an example for using our TLS v1.3 secret logging here:
https://github.com/wolfSSL/wolfssl-examples/pull/251

Thanks,
David Garske, wolfSSL

155

(4 replies, posted in 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,

For TLS v1.3 it is on by default, but you can explicitly set `--enable-tls13` to turn it on.

TLS v1.3 requires the following additional build options (if not using ./configure):

#define WOLFSSL_TLS13
#define HAVE_FFDHE_2048
#define HAVE_HKDF
#define WC_RSA_PSS

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

158

(3 replies, posted in wolfSSL)

Hi Iyyappan,

Can you provide me your build settings? Are you using custom IO callbacks for the LWIP layer or the LWIP socket layer and wolfio.c default implementation? Its possible the callback is not returning the right values.

Since you are using multi-threading I assume you have `FREERTOS` defined for mutex protection. Even so you may not use the same WOLFSSL object from more than one thread. There is a feature you can use to duplicate the WOLFSSL object so you have one for reading and another for writing. If interested that is `HAVE_WRITE_DUP` and `wolfSSL_write_dup`.

Thanks,
David Garske, wolfSSL

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

160

(3 replies, posted in wolfSSL)

Hi Iyyappan,

Can you share a snippet of your code calling wolfSSL_read()? Also can you call `err = wolfSSL_get_error(ssl, 0);` and see if any other error code is returned? Also can you enable logging using DEBUG_WOLFSSL and calling wolfSSL_Debugging_ON()?

I suspect either an issue with heap memory exhausted or the supplied argument to wolfSSL_read invalid.

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 Abhishek,

No, the directory in wolfssl/linuxkm must be excluded. Those files are only for building with the Linux Kernel Module.

Right-click this folder in Project Explorer tree and go to "Properties". Under Resource there is an option to exclude the directory. I am running some tests with the wolfSSL Cube pack v4.7.0 again to make sure my fix for this exclusion is working.

Thanks,
David Garske, wolfSSL

163

(12 replies, posted in wolfMQTT)

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 Kim,

You cannot fix this issue by adding build macros above the options.h in your application. You must compile the wolfSSL library with these settings otherwise the wolfSSL code will not be updated to support 4096-bit keys.

If you use the instructions above for adding CFLAGS to your ./configure it will build the library with these settings and also include them in your options.h.

Perhaps you should send an inquiry to our support@wolfssl.com referencing this forum post for some additional guidance?

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

166

(9 replies, posted in wolfCrypt)

Hi Robert,

I agree, if you model it off AES GCM it should be easy. Feel free to put up a PR with your contribution and I can review/comment. To merge we would need a signed contributor agreement or once you have a license agreement.

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

168

(9 replies, posted in wolfCrypt)

Hi Robert,

There are not current plans to add CCM to the crypto callbacks, but the effort is fairly easy. I've put this on our feature request list.

If this is a blocker for your evaluation please reach out to Rylie and we can escalate it.

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 Tammy,

Which wolfSSL release are you using?

This was fixed in commit and is in the latest wolfSSL v4.7.0 release:
https://github.com/wolfSSL/wolfssl/comm … 7d48d0R685

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

Hi Kim,

I am referring to the thread stack size available. Perhaps you can explain the platform and compiler your are running? For RSA 4096-bit you should have at least 32KB stack available and reduce once it is working. For embedded systems you have a few options to reduce the stack. One is WOLFSSL_SMALL_STACK. Another is using a different math option like SP math (sp_int.c) or normal math (integer.c). Once I understand the platform you are on I can provide some further details.

https://www.wolfssl.com/docs/frequently … tions-faq/
https://www.wolfssl.com/wolfssl-smallst … reduction/

Thanks,
David Garske, wolfSSL

173

(9 replies, posted in wolfCrypt)

Hi Robert,

Thank you for that feedback. I agree with you that the devCtx only makes sense for symmetric algorithms.

Also thank you for the details about your platform (Renesas TSIP). Let me know if you have any other issues or questions.

Thanks,
David Garske, wolfSSL

174

(9 replies, posted in wolfCrypt)

Hi Robert,

I've pushed fixes for this issue to a PR here:
https://github.com/wolfSSL/wolfssl/pull/3874

The `devCtx` is meant for symmetric algorithms. Do you have a need for it with asymmetric ones like ECC or RSA?

Thanks,
David Garske, wolfSSL

Hi Kim,

That error usually indicates an issue with the math size. Is this an RSA 4096-bit key? If so you will need to increase the fast math maximum bits. Try `./configure CFLAGS="-DFP_MAX_BITS=8192" or `#define FP_MAX_BITS 8192`. The other possibility is the stack size could be too small. Try increasing the stack size available and try again.

Thanks,
David Garske, wolfSSL