176

(9 replies, posted in wolfCrypt)

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

183

(12 replies, posted in wolfMQTT)

Hi Remy,

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

Thanks,
David Garske, wolfSSL

184

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

185

(3 replies, posted in wolfCrypt)

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

186

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

187

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

188

(10 replies, posted in wolfSSL)

Hi hp28190,

How do you have the memory setup? I see you have `WOLFSSL_NO_MALLOC` defined, which is odd. It looks like your define for FREERTOS is mapping XMALLOC/XFREE to the pvPortMalloc/vPortFree functions. You need to increase your heap space, which is configured in the FreeRTOSConfig.h. Depending on which FreeRTOS heap implementation you have.

A good template for build options is here:
https://github.com/wolfSSL/wolfssl/blob … settings.h

If you use ./configure from the Linux world it will generate a file wolfssl/options.h, which shows the build options. See ./configure --help for list of enable/disable options.

Thanks,
David Garske, wolfSSL

189

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

190

(10 replies, posted in wolfSSL)

Hi hp28190,

Looks like the client is connecting with TLS v1.2 only based on the wireshark. Also only using the signature algo X25519 (ED/Curve25519). Have you tried omitting the `WOLFSSL_TLS13_MIDDLEBOX_COMPAT` option? Perhaps try adding `HAVE_ED25519`.

Thanks,
David Garske, wolfSSL

191

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

192

(1 replies, posted in wolfSSL)

Hi daniel571,

Yes. We support settings a read/write IO callback and context.

See this useful blog post. https://www.wolfssl.com/wolfssl-custom-io-setup-2/

Let me know if you have any further issues or questions.

Thanks,
David Garske, wolfSSL

193

(1 replies, posted in wolfSSL)

Hi torntrousers,

The wolfMQTT AWS example is located here:
https://github.com/wolfSSL/wolfmqtt#azu … ub-example
https://github.com/wolfSSL/wolfMQTT/tre … ples/azure

The latest work for the RA6M3 is here:
https://github.com/wolfSSL/wolfssl/tree … udio/RA6M3
We also have a PR that adds hardware crypto support here:
https://github.com/wolfSSL/wolfssl/pull/2835

The SCE support is outdated and is being worked on this week. If you would like to find out more please email support@wolfssl.com and tell us a bit more about your project.

Thanks,
David Garske, wolfSSL

194

(6 replies, posted in wolfSSL)

Hi windyMk92,

You might also want to use these API's to set your own IO callback context pointer. This will allow you to specify a different socket/IO context for each thread.

wolfSSL_SetIOReadCtx
wolfSSL_SetIOWriteCtx

Thanks,
David Garske, wolfSSL

195

(6 replies, posted in wolfSSL)

Hi windyMk92,

The attachments are missing. Feel free to email support@wolfssl.com if you cannot post them here.

Is the issue specific to two concurrent threads or just when the STM32F7 is acting as the server? Are you using AES Hardware acceleration? If so have you tried disabling using NO_STM32_CRYPTO?

For multi-threading the common issues are not using mutex protection on the WOLFSSL object between threads. For the WOLFSSL_CTX you should have separate ones. Make sure the server side CTX constructor is using the wolfTLSv1_2_server_method or wolfSSLv23_server_method (to select highest available TLS version and allow downgrade).

We have some excellent TLS examples here: https://github.com/wolfSSL/wolfssl-exam … master/tls

Thanks,
David Garske, wolfSSL

Hi Andreas,

Can you please try updating to the latest wolfSSL GitHub master? There are fixes in since v4.5.0 in aes.c for these STM32 functions.

The latest STM32 Cube MX HAL version I can find is v1.8. I ran our TLS cipher suite test on the H753ZI board with AES crypto hardware acceleration enabled and could not reproduce an issue.

Here is the example I am using:
https://drive.google.com/file/d/1-RIGxq … sp=sharing

Thanks,
David Garske, wolfSSL

Hi Andreas,

I understand, one is using our wolfCrypt software to calculate the AES GCM HMAC. The other is using the STM hardware. Are you able to printout/capture the following variables in the failure case  "sz", "ivSz", "authTagSz" and "authInSz?

What is the version of the STM32 Cube MX Hal code you are using?

Thanks,
David Garske, wolfSSL

Hi AnMu5962,

The issue appears to be related to the AES GCM auth tag calculation. There are fixes for this and this has been tested recently.

Can you confirm you are using the latest wolfSSL master and the latest STM32 Cube MX pack for the H7? Are you using the `STM32_HAL_V2` build option?

If you are using the latest can you print out the "sz", "ivSz", "authTagSz" and "authInSz" being used?

Thanks,
David Garske, wolfSSL

Hi Nevilshute,

It sounds like you were able to resolve it by enabling the Hash security peripheral in the Cube MX tool? Let me know if you have any other issues or questions.

Thanks,
David Garske, wolfSSL

200

(7 replies, posted in wolfCrypt)

Hi Vitus,

I see your bug. In the sign.c see this line `if ((ret = wc_ecc_sign_hash(hash, sizeof(hash), signature, signature_size, &rng, &key)) != 0)`. You are using `sizeof(hash)` and it should be `hash_size`.

Thanks,
David Garske, wolfSSL