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

1 year

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

1
0
0 0

Certificate validation

by Sushma Narayan Shetty

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. ________________________________

1 year, 1 month

2
1
0 0

Testing an an Ubuntu VM, issue with configuration

by Christian Huitema

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

1 year, 1 month

1
1
0 0

UTF-8 in code files

by Stephan Koch

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

1 year, 1 month

3
3
0 0

Using the "psa_verify_message" function

by Christian Huitema

The specification of the "psa_verify_message" function is simple enough: pass a key ID, an algorithm ID, the data that were signed, the signature received from the peer, and receive a status. There is just one tiny problem: in the application, the algorithm ID is specified as a 16 bit TLS SignatureScheme (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-si…), which is not quite the same as "psa_algorithm_t". Is there a simple way to covert from TLS SignatureScheme to PSA ALgorithm identifier? Maybe a two columns table? -- Christian Huitema

1 year, 1 month

2
1
0 0

Error while parsing certificate

by Subramanian Gopi Krishnan

Hi, I have an inhouse developed secure authentication program that uses certificate for authentication. I have used mbedtls library for the x.509 certificate verification purpose. In our custom PKI we have only three level of certificates, Root-CA -> Intermediate-CA -> Device-Cert. The embedded device has very limited memory, so instead of sending whole certificate chain, the devices communicates intermediate_CA and device cert (in der format base64 encoded) in separate packet. Root-CA will be available on node as trusted-ca. Intermediate is verified against Root; then device cert is verified against intermediate. The problem is, the poc developed on linux platform is working fine - but on embedded platform I encounter either 0x3b00(parsing failed) or 0x2700(with flag 8). Also the error code are inconsistent. I verified the integrity of packet with certificate using crc16. So no chance of certificate getting corrupted. Also verified the certificate's base64 format integrity using crc16. All certificates are sha256WithRSAEncryption; RSA Public-Key: (4096 bit) Attached config.h on target platform for reference - could you help me if anything wrong with configuration. While trying to trace, the flag was set from x509_crt.c from below code. /* No parent? We're done here */ if( parent == NULL ) { printf("NO_PARENT\r\n"); *flags |= MBEDTLS_X509_BADCERT_NOT_TRUSTED; return( 0 ); } Any clue would be helpful. Thanks, Gopi Krishnan

1 year, 1 month

2
1
0 0

Help debugging TLS handshake failure

by Jay Malhotra

Hi, I'm having an issue with some code using Mbed TLS and I was pointed to this mailing list as the correct place to ask for support. Please let me know if I should ask somewhere else. I'm trying to connect to my local government's website via a Raspberry Pi Pico, using a TLS client based on lwIP and altcp_tls. It's based off of the example from the Raspberry Pi team here: https://github.com/raspberrypi/pico-examples/tree/master/pico_w/wifi/tls_cl… . My Mbed TLS config is the same as what they have there, aside from some extra defines I added for debugging. The issue I am facing is that while various hosts work fine (e.g. postman-echo.com for testing), when I attempt to connect to my local council's website I get a TLS handshake error. My client has TLS verification disabled for the moment, but I have tried with the correct root certificates as well. The error I receive is mbedtls_ssl_handshake failed: -30592 I cloned down the mbed_tls repo, and had a similar issue with ssl_client1 -- i.e. works on postman-echo, not for my government, with mbedtls_ssl_handshake returning the error. Notably however, the error code in that instance was -31488. Interestingly, ssl_client2 works flawlessly with both hosts. I wasn't quite sure what part of ssl_client2 would cause it to work with my government host, as it's several thousand lines long, but I'm sure the answer is in there somewhere. I've attached a trace taken with debug logging level 4 on my Pico which shows where the TLS handshake is failing. I'd really appreciate any guidance of areas to troubleshoot next. Thanks, Jay

1 year, 1 month

1
1
0 0

Memory Cleanup of Persistent Key Slots

by Zak, Kevin

Hello, I am referencing the Mbed TLS (v3.5) implementation for key slots & how they interact with the PSA key management APIs. In the PSA documentation<https://arm-software.github.io/psa-api/crypto/1.1/overview/implementation.h…>, sections 6.3.3 and 6.3.4 describe that persistent keys (that are handled according to the Memory cleanup rule) would have to be loaded from NVM on each use of the key, unless PSA_KEY_USAGE_CACHE is set. However, I'm not certain I see this followed in the Mbed TLS code. 'psa_export_key()' is the simplest example. This function retrieves and locks the key slot for the requested key ID using 'psa_get_and_lock_key_slot_with_policy()' - this function may retrieve the persistent key material from NVM if necessary (it seems to return sooner if it finds that persistent key in a slot already). The remainder of psa_export_key() copies the key material from the slot directly to the output buffer, but it never removes the key material from the slot. My understanding was that the key material should be removed from the slot unless PSA_KEY_USAGE_CACHE was set. Can anyone clear this up for me? Does this just mean that the reference implementation does not follow the memory cleanup rule, or is the slot buffer cleared at some later point for the persistent key? Thank you, Kevin Zak

1 year, 1 month

2
1
0 0

Reminder: MBed TLS Tech Forum - US/Europe

by Don Harbin

Hi All, A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum is next Monday at 4:30 PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

1 year, 2 months

1
6
0 0

The road towards Mbed TLS 4.0

by Nathan Sircombe

Dear Mbed TLS users, We recently announced the release of Mbed TLS 3.6.0, starting the 3.6 long-term support branch. We intend for this to be the last 3.x feature release. Mbed TLS 3.6.x will as usual receive bug fixes (including security improvements), but no new features. This will allow the Mbed TLS team to focus on preparing the next major release, Mbed TLS 4.0, planned for 2025 (expect further updates when the timeline becomes more precise). The main focus of Mbed TLS 4.0 is to complete the migration to PSA crypto APIs. This means that most mbedtls_xxx cryptography APIs will be removed. We expect mbedtls_x509 and mbedtls_ssl to change in relatively minor, but sometimes incompatible ways. Alongside this technical change, the crypto APIs will be published as a separate product, TF-PSA-Crypto<https://github.com/Mbed-TLS/TF-PSA-Crypto> (very early preview so far), while the X.509 and TLS libraries will continue to be called Mbed TLS. The work on 4.0 will happen on the development branch in the mbedtls repository, so you can expect more instability than usual on that branch. The mbedtls-3.6<https://github.com/Mbed-TLS/mbedtls/tree/mbedtls-3.6> branch is available if you want the latest patches on Mbed TLS 3.6 LTS. As usual, you can see our high-level plans in the roadmap<https://mbed-tls.readthedocs.io/en/latest/project/roadmap/>, and in more detail on GitHub<https://github.com/Mbed-TLS/mbedtls/issues>. Look for issues labeled api-break<https://github.com/Mbed-TLS/mbedtls/issues?q=is%3Aissue+is%3Aopen+label%3Aa…> (note that we haven't filed issues on all topics yet). We will launch some consultations on the mbed-tls mailing list<https://lists.trustedfirmware.org/mailman3/lists/mbed-tls.lists.trustedfirm…> soon, to gather community input on some topics. Many Thanks, Nathan Sircombe (On behalf of the Mbed TLS development team)

1 year, 2 months

3
4
0 0

Introductions

by Nathan Sircombe

Hi Mbed TLS list, I’d just like to introduce myself to the wider Mbed TLS community. I’ve recently joined the Mbed TLS team as the Engineering Manager for the Arm team. Although I’m new to this project, I’m not new to Arm having worked here for a while on a number of closed and open source library projects. I look forward to working with you, and meeting some of you on our regular community calls. Cheers, Nathan. p.s. my GitHub usid is nSircombe (https://github.com/nSircombe)

1 year, 2 months

1
0
0 0

Ask about using mbedtls

by blaine

hello： Recently, I am transplanting mbedtls from a 32-bit system to a 64-bit system. The compilation operating system is ubuntu20.4. The screenshot below is the code I use mbedtls(version number: 2.24.0). In the API mbedtls_rsa_gen_key implementation, there is a line of code that is ""MBEDTLS_MPI_CHK( mbedtls_mpi_lset( &ctx ->E, exponent ) );"", the program crashed at the memset in mbedtls_mpi_set during execution. This has not happened on 32-bit platforms before, so I would like to ask whether it has something to do with the platform used or whether I call the API. It’s a question about how to use it, thank you very much

1 year, 2 months

2
1
0 0

Exports from the shared libraries vs API

by Zaki, Ahmed

Hi, I am trying to identify the API available by looking up exported symbols from the built shared libraries libmbedcrypto.so ,libmbedtls.so and libmbedx509.so. I noticed that many of the exported functions are not documented here https://mbed-tls.readthedocs.io/projects/api/en/development/ . My question really is, are those functions exported through the shared libraries intended to be so ? For example, function mbedtls_mpi_core_add does not seem to be part of the API but it is exported. Is this intentional ? It's not uncommon that functions would be exported but not part of the API, I just wanted to get some clarification if possible regarding the reasons for doing so in the case of MbedTLS. Thanks Ahmed

1 year, 2 months

2
1
0 0

MbedTLS Test Cases

by Satya Prakash Prasad

Hi, I am sorry but I need to know test case scenarios to verify what is supported in the recent MBedTLS stack - what should be tested. Objective is that we cover MBedTLS code the maximum. Since I am a new learner, I need to build the test cases from scratch. So I thought to first find from stack what TLS ciphers suites / digest it supports, what are the different keysize, and protocols - TLSvX (where x=1,2 or 3). Then build certificates related to the same and verify the data as found. Are there other ways to find different features in the current MBedTLs stack and verify each one of them? Is this approach the right way - do we have known test case scenarios to verify? Any other additional help will aid us out. Thanks in advance. Regards, Prakash

1 year, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls