1 Reply by dgarske

(1 replies, posted in wolfBoot)

Hi Snaku,

Thank you for your interest in wolfBoot on the STM32H5 and these excellent questions!

1) This is supported. wolfBoot has two copies (one in each flash bank) and is power fail safe and can be updated
2) Yes this is always true (with or without dual bank)... the application updates are power fail safe.
3) This is handled by ST's OEM-iROT. There are OTP areas that contain root of trust to validate wolfBoot. This area needs a bit of work still and is under development.

You should see an email soon from our business team as we'd love to discuss your project more.

Thanks,
David Garske, wolfSSL

Go to forum: wolfBoot

2 Reply by dgarske

(9 replies, posted in wolfCrypt)

Hi Yin,

The RSA Key Generation is extremely computational and I would expect it to take several minutes on an M0+ at 125MHz. It must find two large primes. The RSA key generation on a device like this is fairly impractical and many companies will load a pre-provisioned RSA key. What is your use-case? Can you tell us more about your project?

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

3 Reply by dgarske

(2 replies, posted in wolfCrypt)

Hi Samuel,

I am not sure how CPPFLAGS and CFLAGS work together during configure. I would typically provide all my options together in a single CFLAGS.

CFLAGS="-arch arm64 -DWOLFSSL_ALT_NAMES"

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

4 Reply by dgarske

(2 replies, posted in wolfSSL)

Hi Ethel Baines,

Also can you tell us more about your project? Is this academic or commercial? Where are you located?

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

5 Reply by dgarske

(2 replies, posted in wolfSSL)

Hi Ethel Baines,

Did you try using our STM32 Cube MX Pack for wolfSSL?

If you are seeing error regarding missing references to wolfSSL_Init then I would check a couple things:

1) Make sure WOLFCRYPT_ONLY is not defined
2) If you are pulling in sources directly and using your own user_settings.h then:
  a) Make sure you have WOLFSSL_USER_SETTINGS defined as a pre-processor macro
  b) You are building the src/*.c and wolfcrypt/*.c. You may have to exclude any .S files.
3) Make sure you include wolfssl/wolfcrypt/settings.h before any other headers. Note: Including wolfssl/ssl.h does this automatically.

We do have some tips for the STM32 Cube platform here: https://github.com/wolfSSL/wolfssl/tree … /STM32Cube

Please let us know how that goes.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

6 Reply by dgarske

(3 replies, posted in wolfBoot)

Hi ClarkS,

Did you also init and update the submodule? The wolfCrypt code is located in a submodule under lib/wolfssl. So please run:

git submodule init
git submodule update

Thanks,
David Garske, wolfSSL

Go to forum: wolfBoot

7 Reply by dgarske

(4 replies, posted in wolfCrypt)

FYI: PR is here: https://github.com/wolfSSL/wolfssl/pull/8693

Go to forum: wolfCrypt

8 Reply by dgarske

(4 replies, posted in wolfTPM)

Hi Bijak Dawid,

Perhaps you can share your code, so I can attempt to reproduce with wolfTPM? Does the tpm2-tools sequence work correctly? If you'd like to keep your code private you can email support at wolfssl dot com.

The most similar examples are probably:
* examples/nvram/policy_nv.c
* examples/boot/secret_seal.c

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

9 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Chinmay,

I implemented some of your feedback in this PR: https://github.com/wolfSSL/wolfssl/pull/8488

In the background we will look at ways to reduce the code size for DTLS v1.3 only.

If you are only a server or client you can use the NO_WOLFSSL_SERVER and NO_WOLFSSL_CLIENT options to reduce code size.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

10 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Chinmay,

Thanks for your interest in our DTLS v1.3 support.

1) You are correct, the build configuration options and template for the ST Cube Pack do not yet have DTLS v1.3.
The configuration template comes from: https://github.com/wolfSSL/wolfssl/blob … t_conf.ftl

For now you can manually add:

#define WOLFSSL_DTLS
#define WOLFSSL_DTLS13

We will work on adding DTLS v1.3 to the template.

2) The DTLS v1.3 code requires DTLS and TLS v1.3 code (for now). Are you seeing an issue with code size? I have logged this as a feature request.

4) The option WOLF_CONF_TLS12 comes from the pack "STM32CubeMX/wolfSSL.I-CUBE-wolfSSL.5.7.6_Configs.xml" file. The GUI generates an option for this: `<Argument AddressOf="false" Comment="WOLF_CONF_TLS12" GenericType="simple" Name="WOLF_CONF_TLS12" OptimizationCondition="equal"/>`.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

11 Reply by dgarske

(1 replies, posted in wolfSSH)

Hi Fred,

When you build wolfssl use ./configure --enable-wolfssh. That will include this `wc_SSH_KDF` API. Please let us know if that does not help. See: https://github.com/wolfSSL/wolfssh?tab= … pendencies

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSH

12 Reply by dgarske

(2 replies, posted in wolfSSL)

Hi Dennis,

Another reason for this could be missing SNI. Make sure you have enabled SNI (HAVE_SNI) and called the API to set the hostname.

See https://www.wolfssl.com/using-server-na … h-wolfssl/

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

13 Reply by dgarske

(2 replies, posted in wolfSSL)

Hi Dennis,

Are you able to capture a Wireshark for this? The client is sending a client_hello and the server is reporting back a handshake failure (40) and closing the socket. Who is the server? Perhaps the server requires TLS v1.3 and you don't have that enabled in your build options. Can you share how you built wolfSSL (user_settings.h file)?

It might be helpful to experiment with a simulator like https://github.com/dolphin-emu/dolphin first.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

14 Reply by dgarske

(1 replies, posted in wolfSSL)

Hi SunnySunday,

Have you reviewed the instructions for setting up the environment here? https://github.com/wolfSSL/wolfssl/tree … CRYPTOCELL

That file should be part of the Nordic SDK.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

15 Reply by dgarske

(3 replies, posted in wolfCrypt)

Hi Mark,

This error with r7 is becuase the cortex-m uses it when building with debug. To get around this you can add 

-fomit-frame-pointer

to your CFLAGS.

I added a note in the STM32Cube pack README.md regarding this:
https://github.com/wolfSSL/wolfssl/tree … pack-usage

If seeing `error: r7 cannot be used in 'asm'` add `-fomit-frame-pointer` to the CFLAGS. This only happens in debug builds, because r7 is used for debug.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

16 Reply by dgarske

(4 replies, posted in wolfSSL)

Hi SunnySunday,

It's been added in PR https://github.com/wolfSSL/wolfssl/pull/7995 and should be merged shortly. It will be in the next release planned in a few weeks.

Can you tell us more about your project and use-case involving connection ID with DTLS v1.2? Feel free to email support at wolfssl dot com if you'd like to keep it confidential.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

17 Reply by dgarske

(4 replies, posted in wolfSSH)

Hi Riker,

The error -229 means the RSA signature verification failed. It could mean the public key presented doesn't match the private key used. It could also be that it's an RSA key size that is not enabled. For example using RSA 4096-bit might require setting SP_INT_BITS 4096. Or perhaps it's trying to use an older SHA-1 or a new SHA2/SHA3 that is not enabled.

Can you share more of the logs or wirehshark? Can you tell us more about the hardware platform running wolfSSH client? Can you share the build settings used for wolfCrypt and wolfSSH?

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSH

18 Reply by dgarske

(10 replies, posted in wolfSSL)

Hi Rickou,

Congratulations! I am happy to hear you got it working. Let us know if anything else comes up.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

19 Reply by dgarske

(10 replies, posted in wolfSSL)

Hi Rickou,

That's odd. Is it the same version of the CubeMX HAL for AES? Are you using the same AES GHASH build options, example: GCM_SMALL or GCM_TABLE_4BIT? The actual AES GCM test happens later. If it also fails then you might check to make sure the clock for the AES peripheral is enabled (__HAL_RCC_AES_CLK_ENABLE();).

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

20 Reply by dgarske

(10 replies, posted in wolfSSL)

Hi Rickou,

GMAC is the integrity portion of AES GCM and can be used like a hashing function. I suspect you won't need GMAC, but I will investigate the root cause with AES GCM HW crypto.

Can you share me your build settings to try and reproduce? With the CubeMX generated code the settings are usually in a wolfSSL/wolfSSL.I-CUBE-wolfSSL_conf.h.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

21 Reply by dgarske

(10 replies, posted in wolfSSL)

Hi Rickou,

This issue was fixed in PR https://github.com/wolfSSL/wolfssl/pull/7787 on July 29, 2024.

Please confirm you are using the latest master or patch your code with this PR.

If you continue to have any issues please let us know.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

22 Reply by dgarske

(3 replies, posted in wolfTPM)

Hi All,

As a followup to this topic, we did add support for getting the endorsement keys/certificates. You can find an example here:
https://github.com/wolfSSL/wolfTPM/tree … ndorsement

The answer to all of these is yes, but it does vary by TPM manufacture.

Let me know if you have any questions after reviewing the new example and endorsement (EK) support.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

23 Reply by dgarske

(11 replies, posted in wolfCrypt)

The memory use is lower for Single Precision (SP) math implementations, which is why using WOLFSSL_HAVE_SP_RSA resolves it for you. It also defaults to using math variables from stack, unless WOLFSSL_SMALL_STACK is used (then it comes from heap.

Thanks, David Garske, wolfSSL

Go to forum: wolfCrypt

24 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Leon,

I've transferred this incident to our internal Zendesk system. This will enable a better channel for communicating the details to help us reproduce and fix.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

25 Reply by dgarske

(1 replies, posted in wolfSSL)

Hi Daniel,

Your use case sounds very interesting and is one we do support. The handshake operations taking the most time are the cryptographic ones for asymmetric operations like shared secret and sign/verify. If you are using an ECC only cipher suite like ECDHE-ECDSA then you can enable our non-blocking crypto with TLS and break operations into much smaller chunks.

When the non-blocking build option is enabled the crypto calls will return WC_PENDING_E and you would just call the wolfSSL_connect/wolfSSL_accept API's again until complete.

This does require our asynchronous code from https://github.com/wolfssl/wolfAsyncCrypt.

We posted a nice blog on it here: https://www.wolfssl.com/wolfssl-bare-me … yptography

This use case is supported and used by many customers. However it might be useful to setup a call to walk you through it and hear about your use case. We will be emailing you directly to reach out.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL