• Registered: 2024-04-01
  • Posts: 3

Topic: non-blocking usage, e.g. with WOLFSSL_SP_ARM_CORTEX_M_ASM

We are attempting to integrate WolfSSL on our automotive product using an NXP S32K344 CPU (Arm Cortex M7). This CPU has hardware support for some cryptographic functions, but we are not using these (yet).

It is important for our application that no call to the WolfSSL library blocks for too long. We therefore want to use as much as possible of the asynchronous features. Another restriction of our setup is that we use static memory allocation.

First we perform the following initialization steps:
- call wolfSSL_init();
- call wolfSSL_CTX_load_static_memory() to configure memory and initialize a WolfSSL context.
- call wolfSSL_CTX_load_verify_buffer_ex() to load a self-signed CA certificate (filetype ASN1)

Then we want to verify a certificate against the CA that has just been loaded. Ideally this could be done by using wolfSSL_CertManagerVerifyBuffer, but that doesn't work since it does not internally handle the WC_PENDING_E return value as a special case. Therefore, we do the following steps instead:

- call wc_InitDecodedCert to initialize a DecodedCert instance "decoded_certificate" containing our certificate.
- set "decoded_certificate.sigCtx.devId" to the value 0.
- call wc_ParseCert, expect return value WC_PENDING_E
- call wolfAsync_EventInit to initialize "decoded_certificate.sigCtx.asyncDev->event"

Then repeatedly call wolfAsync_EventPoll on "decoded_certificate.sigCtx.asyncDev->event".

(1) Is this the intended usage of the API? It appears unlogical that we need to access the fields of "decoded_certificate.sigCtx" directly, but I can not find a way to use asynchronous ECC computations without doing this.

Despite making the ECC computations asynchronous the call to wc_ParseCert is still too slow for us. This is potentially caused by the repeated computation of SHA256 hashes. We can install a callback handler using option WOLF_CRYPTO_CB, but as far as we can see it is not allowed for the hash function callback to return WC_PENDING_E.

(2) Is it correct that any hash function callback provided through "wc_CryptoCb_RegisterDevice" must be blocking?

(3) It appears like we could improve the performance a lot by using the WOLFSSL_SP_ARM_CORTEX_M_ASM option. However, the non-blocking implementation is not available. Concretely, we are missing the definition of struct sp_256_ecc_mulmod_8_ctx and the function sp_256_ecc_mulmod_8_nb (wolfcrypt + wolfasynccrypt v5.6.6).

Share

  • From: Mobile, AL
  • Registered: 2013-12-11
  • Posts: 298

Re: non-blocking usage, e.g. with WOLFSSL_SP_ARM_CORTEX_M_ASM

Hi Siewie,

Welcome to the wolfSSL Forums. We encourage users to send an email to support@wolfssl.com in order to receive the highest priority support.

Here is a short RSA example that will give you an idea of the intended usage:
https://github.com/wolfSSL/wolfAsyncCry … sa-example

> (2) Is it correct that any hash function callback provided through "wc_CryptoCb_RegisterDevice" must be blocking?

No, the callbacks can be implemented as non-blocking, and utilize the async features.

> (3) It appears like we could improve the performance a lot by using the WOLFSSL_SP_ARM_CORTEX_M_ASM option. However, the non-blocking implementation is not available. Concretely, we are missing the definition of struct sp_256_ecc_mulmod_8_ctx and the function sp_256_ecc_mulmod_8_nb (wolfcrypt + wolfasynccrypt v5.6.6).

I'll check with the team on this question.

Thanks,
Eric - wolfSSL Support

embhorn's Website

Share

  • From: Mobile, AL
  • Registered: 2013-12-11
  • Posts: 298

Re: non-blocking usage, e.g. with WOLFSSL_SP_ARM_CORTEX_M_ASM

The non-blocking ECC assembler component (sp_256_ecc_mulmod_8_nb), is a place-holder for future development. Obviously we do intend to implement this feature. If you'd like me to mark you down as interested in this feature, please send an email to support@wolfssl.com

embhorn's Website

Share

  • Registered: 2024-04-01
  • Posts: 3

Re: non-blocking usage, e.g. with WOLFSSL_SP_ARM_CORTEX_M_ASM

Thank you for your quick replies.

I will send an e-mail to state my interest regarding point (3) and also enquire about possible workarounds. In particular, I would be interested to know if I can easily construct a "hybrid" solution myself where I use optimized instructions for blocking computations and fallback to the non-optimized version for non-blocking computations. Another workaround that I could potentially implement myself is something where I would first check (through e.g. a callback to my own application code) if there is enough time remaining. If so, it could simply execute the blocking version. If not, it could return WC_PENDING_E.

In order to clarify point (2): I was specifically talking about the usage of the hash function in a call sequence that starts by a call to the function "wc_ParseCert". This causes multiple invocations of the SHA256 hash function before starting ECC signature verification. The ECC signature verification is non-blocking and returns WC_PENDING_E. What I would have liked is to return WC_PENDING_E already from the hash function, in order to queue all of the remaining operations (both hashing and signature verification) for future handling through "wolfAsync_EventPoll". This does not appear to be possible since the WC_PENDING_E value is not handled as a special return value inside the call sequence that is constructed by "wc_ParseCert".

Share