ESP32 TFM fix for RSA key size 512 and 2048

[gojimmypi]

Description

As described in #6205 RSA signature fails for certain key sizes on the ESP32.

This is an interim fix as described here that reverts to software calculations in the known cases that the hardware acceleration is problematic.

Specifically:

1. For key size 2048 esp_mp_mulmod is not used, instead fp_mulmod is called.

2. For key size 512 esp_mp_exptmod is not used, instead the SW version is used in fp_exptmod.

There's also a new compile-time warning these functions that need a key size but one is not defined: "WOLFSSL_RSA_KEY_SIZE not defined"

See #6234 for a roadmap of all Espressif Improvements.

Fixes zd# n/a

Testing

How did you test?

See details in #6205

Checklist

• added tests
• updated/added doxygen
• updated appropriate READMEs
• Updated manual and documentation

[dgarske]

Is the reason for these issues understood or documented in HW or is the underlying bug/issue not understood yet? I read the #6205 and it seems like the real bug is not identified yet.

[dgarske]

Where is WOLFSSL_RSA_KEY_SIZE documented? Did you consider RSA_MAX_SIZE? Why is the logic not a >= 512? If this is ESP32 specific please use a macro that includes it.

[gojimmypi]

Is the reason for these issues understood? is the underlying bug/issue not understood yet?

No, not yet. I do not know exactly why the hardware-accelerated calc fails for certain RSA lengths. I wanted to at least get a fix in place before diving into the HW. It may take some time to fully resolve this. I chose to instead get other, higher visibility changes in place and backburner this for now.

Where is WOLFSSL_RSA_KEY_SIZE documented?

I neglected to add documentation on WOLFSSL_RSA_KEY_SIZE. I can add it if you are in favor of keeping this, or some other equivalent functionality.

The intent is for this value to be used for explicit user RSA key sizes. We could put this in the default ESP32 user_settings.h.

I didn't use RSA_MAX_SIZE as I wanted to define an explicit size, not a maximum size. Also, it appears other settings may imply a specific RSA_MAX_SIZE value.

Why is the logic not a >= 512

There's a specific problem for lengths of exactly 512 and a different problem for 2048 length.

If this is ESP32 specific please use a macro that includes it.

The TFM library only uses this gate when the WOLFSSL_ESP32WROOM32_CRYPT_RSA_PRI is enabled. Otherwise, I use it in the demo app that I used when testing #6205.

Would you prefer an ESP32-specific name? It would seem best to have a macro for RSA lengths for the end user. The use of this macro in TFM does however, leave a bit to be desired. Once the HW math is fixed, the only use of this would be be the end user when calling something like wc_MakeRsaKey.

[dgarske]

Since this code is only for ESP32 I would remove WOLFSSL_RSA_KEY_SIZE logic and have this check always enabled and document the workaround for HW issue. The WOLFSSL_RSA_KEY_SIZE logic here is too limiting. RSA should support a range of key sizes.

[dgarske]

Since this code is only for ESP32 I would remove WOLFSSL_RSA_KEY_SIZE logic and have this check always enabled and document the workaround for HW issue. The WOLFSSL_RSA_KEY_SIZE logic here is too limiting. RSA should support a range of key sizes.

[gojimmypi]

Since this code is only for ESP32 I would remove WOLFSSL_RSA_KEY_SIZE logic and have this check always enabled and document the workaround for HW issue. The WOLFSSL_RSA_KEY_SIZE logic here is too limiting. RSA should support a range of key sizes.

I partly agree, but I don't want to disable HW acceleration for all RSA key sizes just because some are problematic. I do agree that my solution is a bit wonky, thus the "interim fix" description.

I'm going to convert this to draft and see if I can find the root problem of the HW math so that all sizes work as they should. This also means that in the meantime, any users will still encounter problems on the current release of wolfSSL, as described in #6205

[gojimmypi]

It was definitely a worthwhile exercise to find the root cause. See #6380

So far, I've only been testing the faster keysize = 512, so I have not determined if the TFM problems with fp_add and fp_cmp are the only ones needed for all other key sizes.

[gojimmypi]

This lingering draft PR was fixed some time ago. See also #6205