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
You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → Posts by dgarske
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
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
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
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 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
Hi Robert,
Thanks for the excellent feedback. I did the crypto callback implementation and the devCtx was added a bit later and possibly not consistent across all algorithms (as you have seen). I will work on a fix for and post a link. Also there is some work in progress to fix the HMAC devId's.
In the future feel free to send us a direct email to support@wolfssl.com, which goes into our ZenDesk system.
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,
It looks like the build error is in the example code `IDE/XilinxSDK/wolfssl_example.c`. For now you can wrap those in `#ifndef NO_ASN_TIME` to get past that error. I haven't used that Zynq target (mainly the UltraScale+). I think you would have the best success if you create a new project using the Vitis wizard and then add the wolfSSL project.
Here are the important steps after you create a blank project:
1) Exclude all the wolfSSL directories except "src/*.c", "wolfcrypt/src/*.c" and "IDE/XilinxSDK/*.c".
2) Add include paths to the wolfssl-root/wolfssl directory and the IDE/XilinxSDK directory.
3) Add the pre-processor macro WOLFSSL_USER_SETTINGS
Let me know what errors you see after following these steps.
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 tiagomts,
That is a very uncommon use case. Usually they would be different ports. You could inspect the first 5 bytes to see if its a TLS header and if it was not then treat as clear text. You would need to use custom IO callbacks and add logic to handle the packets without TLS headers. For the non-secure data packets you would need to add your own custom header to know the size. Have you considered using a TLS NULL cipher (HAVE_NULL_CIPHER), which does not encrypt data, but does do the authentication and integrity?
Here is an example using custom IO callbacks:
https://github.com/wolfSSL/wolfssl-exam … callback.c
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 sapi01,
The best epoll examples we have are in wolfssl-examples/tls.
https://github.com/wolfSSL/wolfssl-exam … oll-perf.c
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 hp28190,
I have also seen that error with STM32F7 with the GCM auth tag calculation using the crypto hardware. There have been several fixes some post v4.6.0, so you might consider trying latest master.
Example of PR fix:
https://github.com/wolfSSL/wolfssl/pull/3649
Some other things you can consider trying are:
1. Add the define `STM32_HAL_V2`.
2. Make sure you are using the latest STM32 Cube HAL for the F7.
3. For performance speedups with the latest STM32 Cube you can consider trying STM32_AESGCM_PARTIAL.
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,
Look in wolfcrypt/src/port/arm and you will see addition algorithm specific .c files you will need to include for Aarch64.
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
wolfSSL - Embedded SSL Library → Posts by dgarske
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.013 seconds (54% PHP - 46% DB) with 5 queries