1 Reply by siewie

(3 replies, posted in General Inquiries)

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".

Go to forum: General Inquiries

2 Topic by siewie

(1 replies, posted in wolfCrypt)

See also my other question for more details about our application: https://www.wolfssl.com/forums/topic210 … xmasm.html

We are using static memory and non-blocking ECC computation with wolfSSL/wolfCrypt. When initializing the "DecodedCert" instance using "InitDecodedCert" we provide a non-NULL "heap" pointer.

When calling "ParseCert" we eventually get the following call stack:
ParseCert ->
ParseCertRelative ->
ConfirmSignature ->
wc_ecc_verify_hash ->
wc_ecc_verify_hash_ex->
wc_ecc_check_r_s_range ->
wc_ecc_curve_load

In the function "wc_ecc_curve_load" there is a call to the macro XMALLOC in which a NULL-pointer is passed for the "heap" parameter. This means we can not directly use the WolfSSL memory API functions provided when using the option USE_WOLFSSL_MEMORY.

This problem occurs with wolfSSL+wolfasynccrypt v5.6.6 and v5.7.0.

We currently work around this by using XMALLOC_OVERRIDE, and having our own malloc function which "fills in" the missing heap pointer before calling the wolfSSL_Malloc function.

Go to forum: wolfCrypt

3 Topic by siewie

(3 replies, posted in General Inquiries)

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).

Go to forum: General Inquiries