- mbed-tls - lists.trustedfirmware.org

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

11 months, 3 weeks

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.

12 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

12 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

12 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

12 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

12 months

1
0
0 0

Request for feedback about Mbed TLS 4: partial ECC acceleration

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/TF-PSA-Crypto/issues/103 We are removing all the ALT interfaces to implement hardware-accelerated cryptography, in favor of PSA drivers. For the most part, PSA accelerator drivers provide equivalent functionality to ALT interface. However, there is one main exception: the ECC code allows replacing just code ECC arithmetic (MBEDTLS_ECP_ALT) or even just selected functions (sub-options of MBEDTLS_ECP_INTERNAL_ALT). On the other hand, the granularity of PSA accelerators is whole mechanisms: ECDH, ECDSA, etc. on a specific set of curves. If you are currently using MBEDTLS_ECP_ALT or MBEDTLS_ECP_INTERNAL_ALT to implement accelerated ECC airthmetic and relying on code from ecp.c, ecdh.c and ecdsa.c to provide ECC mechanisms, please let us know what your requirements are and how much of a pain it would be to have to fully implement ECDH/ECDSA/... in your driver. Best regards, -- Gilles Peskine Mbed TLS developer

12 months

1
0
0 0

Request for feedback about Mbed TLS 4: RSA private key import

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/TF-PSA-Crypto/issues/105 Mbed TLS 4 and TF-PSA-Crypto will complete our migration to PSA cryptography APIs. For simplicity, PSA only requires implementations to support complete representations RSA private keys, where all the fields are provided (n, e, d, p, q, dp, dq, u). Thus, with only PSA APIs, it is not possible to import an RSA private key without the public exponent, or an RSA private key without the CRT parameters. Should TF-PSA-Crypto provide an extension to support such private keys? If you need this, please let us know about your use case. Best regards, -- Gilles Peskine Mbed TLS developer

12 months

1
0
0 0

Request for feedback about Mbed TLS 4: custom ECC mechanisms

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/TF-PSA-Crypto/issues/102 Mbed TLS 4 and TF-PSA-Crypto will complete our migration to PSA cryptography APIs, which are higher-level than the legacy mbedtls_xxx() APIs in Mbed TLS ≤3.x. As a consequence, the API will only provide access to ECC-based cryptographic mechanisms such as ECDH, ECDSA and ECJPAKE. (ECIES can be implemented on top of ECDH. Support for EdDSA and SPAKE2+ is planned, but might not be ready at the 4.0 release time.) It will not provide access to ECC arithmetic functions such as mbedtls_ecp_muladd(). Do you need custom ECC-based mechanisms (e.g. custom PAKE)? If so, please let us know which mechanisms and what arithmetic they require. We are not currently planning to make it possible to use such mechanisms without patching the TF-PSA-Crypto code. Best regards, -- Gilles Peskine Mbed TLS developer

12 months

1
0
0 0

Request for feedback about Mbed TLS 4: custom RSA mechanisms

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/TF-PSA-Crypto/issues/104 Mbed TLS 4 and TF-PSA-Crypto will complete our migration to PSA cryptography APIs, which are higher-level than the legacy mbedtls_xxx() APIs in Mbed TLS ≤3.x. As a consequence, the API will only provide access to RSA-based encryption and signature mechanisms (PKCS#1v1.5 encryption, OAEP, PKCS#1v1.5 signature, RSS), not to the low-level RSA-public and RSA-private operations. Do you need custom RSA-based mechanisms (e.g. full-domain encryption or hashing)? If so, please let us know. We are not currently planning to make it possible to use such mechanisms without patching the TF-PSA-Crypto code. Best regards, -- Gilles Peskine Mbed TLS developer

12 months

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls