- mbed-tls - lists.trustedfirmware.org

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, 4 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, 4 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, 4 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, 4 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

1 year, 4 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

1 year, 4 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

1 year, 4 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

1 year, 4 months

1
0
0 0

Request for feedback about Mbed TLS 4: DES (including 3DES)

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/9164 We are considering fully removing DES, including 3DES, from the library. Is any DES variant still relevant to Mbed TLS users these days? If you want Mbed TLS 4 to include DES, please let us know what you're using it for. Reasons to remove: it's long obsolete, and no longer accepted even by NIST except to handle legacy data. Removing it would be one less module to support and would allow generic block cipher code to focus on modern ciphers with 128-bit blocks. Best regards, -- Gilles Peskine Mbed TLS developer

1 year, 4 months

1
0
0 0

MBEDTLS Default Search Path

by Frozen Forest

I am trying to build *https://github.com/ithewei/libhv <https://github.com/ithewei/libhv>* with MBEDTLS on Windows but it doesn't have include and library define options on *CMake*. When I ask them with an issue on *GitHub*, they said I need to use *"Default Search Path"*. I installed it with *cmake --build . --config Release --target INSTALL *and I can see it in *Program Files/MBed TLS. *I think I need to define an environment variable. But what is correct names for includes and libraries ?

1 year, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls