Customizing user_settings.h

[5p4k]

I would like to import esp-wolfssl as a git submodule directly, and yet be able to customize the settings. user_settings.h by default disables unsafe features, which unfortunately we need (specifically, we need 3DES, which is disabled by the macro NO_DES3).

At the moment it seems that the only possibility is to manually modify port/user_settings.h; this is because it is included directly by wolfssl source. This inclusion is controlled by the WOLFSSL_USER_SETTINGS macro, which is set directly in component.mk.

Is there some macro I am missing? Otherwise, would it be possible to change port/user_settings.h in a way that it can be customized without needing to touch the repo content?

For example, something like this:

#ifdef ESP_WOLFSSL_CUSTOM_USER_SETTINGS
#include <esp_user_settings.h>  // File provided by the user, not bundled in esp-wolfssl
#else
// all the content of port/user_settings.h
#endif

[gojimmypi]

Hi @LizardM4 have you seen the latest wolfssl examples? I recently added a feature that allows just a single CMakeLists.txt file in the local project ./components/wolfssl/ directory. The respective user_settings.h would be created in the root of the wolfssl clone directory.

Please give it a try and if you encounter any problems, you can open an issue there and I can help you further.

[5p4k]

Hi @gojimmypi ! I went through the examples; I didn't have time yet to adapt this to our project, but here's my understanding of the CMakeLists.txt: it selects wolfssl's source tree, points there the necessary variables, and if missing, copies there some user_settings.h. Is this correct?

If wolfssl is loaded as a submodule, it would be better not to copy into the clone folder (otherwise the submodule will be dirty), but at that point I could add an include directory to anywhere in the project, so that wolfssl can pick up my user_settings.h. This would effectively bypass this repo and directly pull wolfssl's source; is this what you suggest?

In fact, now that I look at it in this way, it doesn't seem to be very difficult to create my own component. Something like:

• components/wolfssl/wolfssl
  actual submodule pointing to wolfssl source
• components/wolfssl/custom_include/user_settings.h
  customized settings
• components/wolfssl/CMakeLists.txt
  similar to the CMakeLists.txt of the examples, would load wolfssl from components/wolfssl/wolfssl and inject an include directive for components/wolfssl/custom_include
  • components/wolfssl/component.mk
    with adjusted paths and extra include

For context in case someone else happens upon this issue, at the moment I hacked together a solution by adding an -iquote custom_include_path to the compile options. The file user_settings.h is included via quote-include #include "", but the directory where the user_settings.h is located is specified with -I, and -iquote takes priority.

[5p4k]

@gojimmypi I tried the examples you linked, I can compile them. I also managed to get my own app to link successfully with wolfssl and custom user_settings.h, copying CMakeLists.txt and component.mk and customizing the path that points to wolfssl. I had to use the current wolfssl master; it contains some some fixes for including the correct FreeRTOS files that versions 5.4.0 (currently bundled in the official esp-wolfssl) and 5.5.4 (currently the most recent stable) do not contain.

However, I had troubles getting ESP-TLS to work with this wolfssl setup. First of all, the component folder must be called esp-wolfssl, because ESP-TLS queries some component properties under this name. Secondly, I had to add also the Kconfig, because otherwise it does not detect CONFIG_TLS_STACK_WOLFSSL and prevents enabling wolfssl over mbedtls. Third, I have compile errors in esp_tls_wolfssl.c:47, esp_tls_wolfssl.c:306 and esp_tls_wolfssl.c:449, which I think simply follow from the fact that esp-tls has compatibility with version 5.4.0 and not 5.5.4 and beyond.

In conclusion, at the moment the viable options to customize esp-wolfssl and the user_settings.h are the following:

1. Hack: use esp-wolfssl as a submodule, and add -iquote custom_include_path to inject custom_include_path/user_settings.h with a higher priority over esp-wolfssl/port/user_settings.h.
2. Partial re-vendoring: renounce using esp-wolfssl and instead create my own component adapting the CMakeLists.txt and component.mk from wolfssl's examples. This allows me to keep wolfssl as a submodule, but I have to use a currently unsupported version, that is incompatible with ESP-TLS.
3. Fork: fork this esp-wolfssl repository and modify user_settings.h for my need.

[gojimmypi]

Hi @LizardM4 thanks so much for your feedback! That's a great idea! I've created https://github.com/wolfSSL/wolfssl/issues/6118 to track this in the wolfSSL repo.

That's an interesting observation about the ESP-TLS and esp-wolfssl. Thanks for sharing your findings. My recommendation is to use wolfSSL libraries directly rather than though compatibility / interoperability layers. There's less complexity, smaller code side, and likely higher performance and better security.

That said, I realize that may be easier said than done. I'll see what I can do to maximize the "it just works" everywhere.

At the moment, I'm just finishing up some relatively major changes to the wolfSSL ESP32 libraries, particularly surrounding hardware acceleration. See my ED25519_SHA2_fix branch. I'm getting fairly close to wrapping things up and creating a PR.

I'm curious as to what your use-case is for wolfSSL? Do you have any project details you can share? If it is something private, you can email me the details at jim@wolfssl.com

Thanks again for the details and suggestions! I appreciate all the useful information that you've shared.

[5p4k]

I've created https://github.com/wolfSSL/wolfssl/issues/6118 to track this in the wolfSSL repo.

Thank you very much @gojimmypi! Having a project-specific user_settings.h that is not necessarily physically located in the wolfssl clone directory is a very useful feature, and has the benefit of cutting the build step down by one stage (i.e. copying configuration files).

My recommendation is to use wolfSSL libraries directly rather than though compatibility / interoperability layers. There's less complexity, smaller code side, and likely higher performance and better security.

Agreed. The changes in the master already help a lot in this direction, eliminating the need for the port/FreeRTOS.h and port/smphr.h files in this repo. With the user settings file on top, it becomes easy to bundle a separate component. Then Espressif has to step in if they want to improve the integration of their esp-tls layer, but at least from the user perspective this becomes much more flexible.

I'm curious as to what your use-case is for wolfSSL.

I am developing a door access application using NFC cards, on ESP32, with our hackerspace, Mittelab. This is composed of a library implementing the NFC layer and the crypto, and an app on top of it.

The crypto layer uses very basic primitives, essentially just 3DES and AES128 block ciphers, but we are bound by the NFC card hardware to have working support for DES, 2TDEA and 3DES (since the default card keys are DES), hence the need for insecure crypto. We have dual support for MbedTLS and wolfSSL.

The door application employes asymmetric crypto too, and since we are pretty constrained on RAM, we use elliptic curves (to avoid sacrificing 4K for each keypair), ED25519 was the to-go curve. MbedTLS is pretty limited on that, at some point I would have had to roll my own implementation of ECIES. When we started experimenting with EdDSA, I just switched over to wolfssl (among other things, documentation is way better, imo).

However, I did not want to have two keys for ED25519 and Curve25519 operations, and although I had written my own conversion function using wolfssl curve-point functions, I was not confident with it. I found https://github.com/wolfSSL/wolfssl/issues/49 but I did not see any progress in that direction. So, in fact, we eventually abandoned wolfssl for the door application and use libsodium, because it takes care of all these details... nonetheless, I keep supporting wolfssl in the base library.

[gojimmypi]

@LizardM4 That sounds like a very cool project!

Thank you for the suggestion on having an API to convert Ed25519 keys to Curve25519 keys. I checked and confirmed that feature is still on the to-do list. However, there's have been an extremely tiny number of requests since that issue 8 years ago (actually just you).

That said, it is also not likely a huge effort. I suggest you ping the folks at support@wolfssl.com and reference this issue. It sounds like this would be a good investment. Plus of course, there's an option for ongoing support for your project - particularly if it ends up being a commercial product. Priority support, even for an open source project can really make a difference. If you've already done much of the work, perhaps open a PR? Note that you'd need to sign a contributor agreement to get it merged. But that too, may be worthwhile? Clearly you have many valuable ideas to contribute.

In any case, I appreciate all the excellent feedback on wolfSSL. Cheers.