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
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
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
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
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
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
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
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
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
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 ?