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 ?
Hi Team,
Need support on one the below query. I had previously raised this in issue #9116 : Client certificate verify · Issue #9116 · Mbed-TLS/mbedtls · GitHub<https://github.com/Mbed-TLS/mbedtls/issues/9116> .However I was asked to redirect the query to the mbedTLS support.
Q#1 : I have a client certificate chain (end entity cert, intermediate cert and root cert) and I have got 1 public key (extracted from root CA cert) on my server. Is there any way in mbedTLS where I can validate the client certificate using just the public key of the root CA and not the whole root CA certificate on my server?
As per my understanding of CA and certificate validation we would need a whole CA cert and not just the public key of the root certificate. However, I would like to know if there are any API's in mbedTLS for this validation?
Thanks,
Sushma
________________________________
Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient of this message , or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. Email transmission cannot be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender, therefore, does not accept liability for any errors, omissions or contaminations in the contents of this message which might have occurred as a result of email transmission. If verification is required, please request for a hard-copy version.
________________________________
I am testing a test program in an Ubuntu VM, and I have an issue.
I started by configuring MbedTLS in "full" mode (scripts/config.py
full), but in that case the linker fails, "in function
`psa_load_builtin_key_into_slot`, psa_crypto_slot_management.c:
undefined reference to 'mbedtls_psa_platform_get_builtin_key`.
I can suppress the error by editing `include\mbedtls\mbedtls_config.h`
and removing the option `MBEDTLS_PSA_CRYPTO_BUILTIN_KEYS`. The compile
succeeds, but the call to `psa_crypto_init` fails when initializing the
RNG module.
I am struggling. I must be making some mistake, I will keep trying to
understand, but I would appreciate a little bit of help!
-- Christian Huitema
Hello Mbed TLS team,
Mbed TLS 3.6 introduced the first UTF-8 characters “±” in source code, see mbedtls_config.h, line 4179:
* at the same pace. The typical accuracy of an RTC crystal is ±100 to ±20 parts
Is this intended?
Thanks
Stephan