- mbed-tls - lists.trustedfirmware.org

Request for feedback about Mbed TLS 4: RSA decryption cipher suites

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/8170 We are considering removing support for RSA and RSA-PSK key exchanges in Mbed TLS 4. These are cipher suites that use RSA encryption, as opposed to cipher suites using a key agreement (ECDHE) plus RSA signature. These key exchanges are hard to implement securely (we believe we got it right, but it's very delicate code), and they add significantly to the complexity of the TLS code. They have been formally deprecated for a long time and were removed in TLS 1.3. However, I'm aware that some ecosystems are clinging to RSA key exchange. Are RSA-encryption key exchanges still relevant for Mbed TLS? If you want Mbed TLS 4 to keep supporting RSA-encryption cipher suites in TLS 1.2, please let us know and tell us about your use cases. Best regards, -- Gilles Peskine Mbed TLS developer

1 year, 2 months

1
1
0 0

Request for feedback about Mbed TLS 4: AESNI without compiler intrinsics

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/8231 We currently have two implementations of accelerated AES on x86_64 using AESNI (Intel AES acceleration): using assembly or using compiler intrinsics. The assembly code works with GCC and Clang without any compilation options, but not with MSVC. The intrinsics work with MSVC, but not with ancient GCC/Clang and they require compiling at least aesni.c with suitable CPU variant options (e.g. -maes -mpclmul for Clang). We're considering removing the assembly implementation. Is there still interest in compiling AESNI support with older compilers or with simple build systems that don't pass machine options? Best regards, -- Gilles Peskine Mbed TLS developer

1 year, 2 months

1
0
0 0

How to read ecp private key

by arun.lal＠intel.com

I am generating a ECP key in following way. And now how do I get the private key? TEE_Result gen_ec_keys(mbedtls_pk_context* pk, mbedtls_entropy_f_source_ptr f_source, __maybe_unused TEE_Param params[TEE_NUM_PARAMS]) { int ret = 1; mbedtls_entropy_context entropy; mbedtls_ctr_drbg_context ctr_drbg; const char* pers = "gen_key"; TEE_Result res = TEE_SUCCESS; unsigned char output_buf[16000]; memset(output_buf, 0, 16000); mbedtls_entropy_init(&entropy); mbedtls_ctr_drbg_init(&ctr_drbg); if ((ret = mbedtls_entropy_add_source(&entropy, f_source, NULL, 48, MBEDTLS_ENTROPY_SOURCE_STRONG)) != 0) { params[2].value.a = 1; goto exit; } if ((ret = mbedtls_ctr_drbg_seed(&ctr_drbg, f_entropy, &entropy, (const unsigned char*)pers, strlen(pers))) != 0) { mbedtls_printf(" failed\n ! mbedtls_ctr_drbg_seed returned -0x%04x\n", (unsigned int)-ret); params[2].value.a = 2; goto exit; } if ((ret = mbedtls_pk_setup(pk, mbedtls_pk_info_from_type(MBEDTLS_PK_ECKEY))) != 0) { EMSG(" failed\n ! mbedtls_pk_setup returned -0x%04x", (unsigned int)-ret); params[2].value.a = 3; goto exit; } if ((ret = mbedtls_ecp_gen_key(MBEDTLS_ECP_DP_SECP384R1, mbedtls_pk_ec(*pk), mbedtls_ctr_drbg_random, &ctr_drbg)) != 0) { EMSG(" failed\n ! mbedtls_ecp_gen_key returned -0x%04x", (unsigned int)-ret); params[2].value.a = 4; goto exit; } exit: mbedtls_ctr_drbg_free(&ctr_drbg); mbedtls_entropy_free(&entropy); return res; }

1 year, 3 months

4
4
0 0

Re: PSA Cryptoprocessor Driver Interface

by Shebu Varghese Kuriakose

+ Mbed TLS mailing list as well for visibility and any comments. Regards, Shebu From: Zhang, Hao via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, June 5, 2024 12:37 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA Cryptoprocessor Driver Interface Hi TF-M community, TF-M allows Semiconductor vendors to plug in their HW accelerator using PSA cryptoprocessor driver interface. I have a couple of questions in terms of the driver interface. 1. To port customized HW accelerator to TF-M's Crypto service for TF-M v2.1.0 LTS using driver interface, for the multipart operation, https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa… states that "A driver that implements a multi-part operation must define all of the entry points in this family as well as a type that represents the operation context." Take aead encrypt as an example, if the underlying hardware does not support aead_abort, could it implements aead_abort by simply return PSA_ERROR_NOT_SUPPORTED? 1. The driver interface depends heavily on psa_crypto_driver_wrappers.h to dispatch operations to customized HW accelerator, where the psa_crypto_driver_wrappers.h file is automatically generated by scripts/data_files/driver_templates/psa_crypto_driver_wrappers.h.jinja. To port customized HW accelerator to TF-M's Crypto service for TF-M v2.1.0 LTS, would the approach be creating a customized psa_crypto_driver_wrappers.h.jinja file, the driver description file in JSON, and entry point functions. If so and we are considering upstreaming TF-M in the future, all these files would go inside platform/ext/accelerator/<vendor name>. Efforts need to be made so files such as psa_crypto_driver_wrappers.h.jinja should point to mbedtls, right? Additionally, as .jinja is retiring (mentioned in another email exchange), how would semi vendors update psa_crypto_driver_wrappers.h in the future? [https://opengraph.githubassets.com/c87e79773a7fb0841ea038f7cf3dfdf4170debb8…]<https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa…> mbedtls/docs/proposed/psa-driver-interface.md at zephyr * zephyrproject-rtos/mbedtls<https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa…> mbedtls module for Zephyr, this is not a mirror of the official mbedtls repository. - zephyrproject-rtos/mbedtls github.com Thank you very much! Best regards

1 year, 3 months

3
4
0 0

mbedtls_x509_dn_gets(): Different DN string for 2.28.8 and 3.6.0

by Almut Herzog

Hi, Not sure whether I should report this as a bug or maybe an enhancement issue or maybe it is as-designed: I recently migrated from 2.28.8 to 3.6.0 and noticed: An X.509 certificate DN coded as T61 string (done automatically so by openssl for a DN that contains an underscore) is returned as a hex string in 3.6.0 while it is returned as a regular, human-readable string in 2.28.8. As this is not working for us I patched mbedtls_c509_dn_gets() locally as shown below. Please feedback whether you want me to report an issue or if the 3.6.0 behavior is as-designed for a good reason. Best regards, /Almut --- mbedtls-3.6.0_orig/library/x509.c 2024-03-28 09:59:12.000000000 +0100 +++ mbedtls-3.6.0/library/x509.c 2024-05-21 10:43:43.327442284 +0200 @@ -840,9 +840,7 @@ MBEDTLS_X509_SAFE_SNPRINTF; } - print_hexstring = (name->val.tag != MBEDTLS_ASN1_UTF8_STRING) && - (name->val.tag != MBEDTLS_ASN1_PRINTABLE_STRING) && - (name->val.tag != MBEDTLS_ASN1_IA5_STRING); + print_hexstring = !MBEDTLS_ASN1_IS_STRING_TAG(name->val.tag); if ((ret = mbedtls_oid_get_attr_short_name(&name->oid, &short_name)) == 0) { ret = mbedtls_snprintf(p, n, "%s=", short_name);

1 year, 3 months

1
0
0 0

What is the right way to use ecp

by arun.lal＠intel.com

I have a very basic use case, to use a buffer and perform ECDSA encryption in a TA application. I also want to read back the private key which is generated. I see functions like mbedtls_ecp_gen_key but I have failed to find enough details on what steps to follow to use this function. It will be really helpful if I can be pointed to a example. Or let me know If there is some other way to achieve the end goal.

1 year, 3 months

2
3
0 0

Are you requesting feedback about ED25519?

by Christian Huitema

Hello Gilles, I see that you are requesting feedback on a set of issues, but not on support of EdDSA. Yet, support for ED25519 is an important requirement for TLS and QUIC. With other crypto suites, the CPU load is significantly lower for ED25519 than for ECDSA/secp255r1. Somewhat related, but there is also demand for ChaCha20-poly1035, for performance reason on some systems. Are there any plans? -- Christian Huitema

1 year, 3 months

2
1
0 0

Request for feedback about Mbed TLS 4: CBC cipher suites

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/9202 In 2025 (by the time Mbed TLS 4.0 is released), are CBC-based cipher suites still relevant for Mbed TLS? If you still need support for CBC-based cipher suites (as opposed to cipher suites using AEAD: CCM, GCM or ChaChaPoly, or null cipher suites), please let us know. Removing them would allow us to significantly simplify some parts of the TLS code. They are difficult to implement securely due to being very sensitive to side channels; we think we got it right, but at the expense of performance, code size and maintainability. One option we're considering is to keep CBC cipher suites, but only when the encrypt-then-MAC (EtM) extension is enabled. However, this is problematic because the TLS protocol does not allow a client to indicate that it requires EtM support, which could lead to a failed connection even when the server also have an AEAD cipher suite in common. Best regards, -- Gilles Peskine Mbed TLS developer

1 year, 3 months

1
0
0 0

Request for feedback about Mbed TLS 4: static ECDH cipher suites

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/9201 We are considering removing static ECDH cipher suites. (Mbed TLS has never supported static non-EC DH.) They are officially deprecated by RFC 9325. OpenSSL dropped them in 2016. If you want Mbed TLS 4.0 to continue supporting ECDH, please let us know in what ecosystem they're still relevant. Best regards, -- Gilles Peskine Mbed TLS developer

1 year, 3 months

1
0
0 0

Request for feedback about Mbed TLS 4: dynamic secure element drivers

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4,0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/8151 We are planning to remove the dynamic secure element interface enabled by MBEDTLS_PSA_CRYPTO_SE_C, in favor of PSA secure element drivers declared at compile time. The functionality is the same, but with a cleaner interface (we learned from the first draft). However, this does mean that all drivers must be declared at compile time. If you are currently using MBEDTLS_PSA_CRYPTO_SE_C and relying on runtime declaration of drivers, please let us know about your use case, so that we can try to find an alternative solution. Best regards, -- Gilles Peskine Mbed TLS developer

1 year, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls