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

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

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

Hi Tom,

Something with your library configuration for the link step looks wrong.

`cannot find -l-Wl,--start-group,-lxil,-lgcc,-lc,--end-group`. That is not valid syntax... the leading `-l` should not be there. Please double check your library settings in your project.

Thanks,
David Garske, wolfSSL

Hi Tom,

The error with `xrtcpsu.h` is for RTC time support in your BSP. You would need to enable support for this in your platform or you can disable time support by adding `NO_ASN_TIME` to your user_settings.h.

I think it would be helpful to setup a call to discuss your project. Would you mind sending a direct email to facts@wolfssl.com referencing this forum post and a way to contact you?

Thanks,
David Garske, wolfSSL

Hi sapi01,

Yes feel free to put up a PR. In order to merge it we would need a signed contributor agreement. For that please email support@wolfssl.com with your contact information and a link to the PR once it is posted.

Thanks,
David Garske, wolfSSL

Hi Remy,

In your crypto callback just return `CRYPTOCB_UNAVAILABLE` and it will fallback to using software operations.

Thanks,
David Garske, wolfSSL

Hi stroebeljc,

The AES CCM IV range 7-13 bytes is defined in the NIST 800-38C
https://nvlpubs.nist.gov/nistpubs/Legac … 00-38c.pdf

The AES CCM algorithm appears that it could handle up to 16-bytes, but it would break compatibility with the specification. I believe the intent of limiting the IV is to reduce the maximum number of bytes that can be encrypted before having to re-key.

Thanks,
David Garske, wolfSSL

Hi sEdwards,

You will find those missing functions in wolfcrypt/port/arm/armv8-poly1305.c. Make sure you are including this file in your project.

Thanks,
David Garske, wolfSSL

Hi hp28190,

For the ATECC we've got some examples and demo videos available.

See this repo for our ATECC specific examples:
https://github.com/wolfSSL/microchip-atecc-demos/

Here are two demo videos for using the ATECC with wolfSSL (Microchip ShieldsUp webinar 24 and 29:
https://www.youtube.com/watch?v=bEPG5p7CMzA
https://drive.google.com/drive/folders/ … sp=sharing

You need to have the CryptoAuthLib and set a couple of build options. This page explains the difference between the ATECC provisioning options:
https://www.microchip.com/design-center … t-platform

Thanks,
David Garske, wolfSSL

Hi windyMk92,

Can you share what your IO read/write callback functions look like (my_EmbedReceive)? Also can you send your logs to review?

You might try using the WOLFSSL_ALT_CERT_CHAINS build option. I've noticed some FTP servers include an additional certificate not in the chain.

Thanks,
David Garske, wolfSSL