- mbed-tls - lists.trustedfirmware.org

by Solis, Hector

Hi! We are working with Mbed TLS 3.6.0 library and need the following information: 1. Is there any End-Of-Life date planned for this library? 2. What is the current version? 3. How can we obtain support for the library enquiries? Does this support has a cost? 4. How is the library update? Does this update has a cost? 5. Are this library Open Source? Thanks in advance for your help! 🙂 Have a great day! Héctor J. Solís Castillo Embedded Engr I Honeywell | HTS Building Automation 990, Av. Eje 5 Norte, Mexico City CDMX hectorjose.solis(a)honeywell.com<mailto:hectorjose.solis@honeywell.com> honeywell.com<http://www.honeywell.com/> Pronouns: He/Him<https://www.mypronouns.org/what-and-why>

6 months, 2 weeks

2
1
0 0

Question about partial certificate chains

by Roman Janota

Hello, I have the following two certificate chains: server <- intermediateCA <- rootCA and client <- intermediateCA <- rootCA. Currently there are two ways the client is authenticated by the server: both the intermediateCA and rootCA certificates are configured as CAs on the server or if only intermediateCA is configured. I am using a custom verify callback set by mbedtls_ssl_conf_verify(). I would like to achieve two separate cases: 1) Make the MbedTLS' built-in pre-verify be successful, even when only the rootCA certificate is set as the server's CA. 2) Always obtain the whole certificate chain up to the root in the verify callback. For case 1) this is how our OpenSSL TLS implementation works, it is discussed here <https://github.com/openssl/openssl/issues/7871>. From my understanding the server should be able to build the certificate chain by inquiring the client about its certificate's issuer, etc. For case 2), whenever both rootCA and intermediateCA are configured on the server, only the chain client <- intermediateCA is received by the callback. I would like to be able to receive the chain client <- intermediateCA <- rootCA. Are these two cases achievable with mbedTLS? For reference I am using mbedTLS 3.5.2. For my server I would like to utilize both cases 1) and 2) and for the client only the case 1). Kind regards, Roman Janota

6 months, 3 weeks

1
0
0 0

PSA Crypto API version compliance

by Zak, Kevin

Hello, I notice in 'crypto.h' of mbedTLS 3.6.3, PSA_CRYPTO_API_VERSION_MAJOR & PSA_CRYPTO_API_VERSION_MINOR show the version implemented as v1.0. Per the github page of TF-PSA-Crypto (https://github.com/Mbed-TLS/TF-PSA-Crypto/blob/development/README.md), the implementation is of v1.1. I verified that this mismatch between the README and crypto.h exists on the development branch of TF-PSA-Crypto as well. What is the correct version implemented, as of mbedTLS 3.6.3? Regards, Kevin

6 months, 4 weeks

1
0
0 0

(no subject)

by Steve Glass

Hi, I'm trying to build the mbedtls v3.6.3 for an embedded 386 device. The build is configured as `crypto_baremetal`. In the snippet below I use the make build process with a GCC 11.2 cross toolchain that's installed in `/opt/x-tools/i386-elf but the build process ends with an error: ``` (venv) dev [ /workspaces/mbedtls ]$ make CC=/opt/x-tools/i386-elf/bin/i386-elf-gcc AR=/opt/x-tools/i386-elf/bin/i386-elf-ar make[1]: Entering directory '/workspaces/mbedtls/library' CC aes.c CC aesni.c CC aesce.c ... CC src/certs.c CC src/psa_test_wrappers.c CC src/test_helpers/ssl_helpers.c make[1]: Leaving directory '/workspaces/mbedtls/tests' make[1]: Entering directory '/workspaces/mbedtls/programs' CC aes/crypt_and_hash.c /opt/x-tools/i386-elf/lib/gcc/i386-elf/11.2.0/../../../../i386-elf/bin/ld: cannot find crt0.o: No such file or directory collect2: error: ld returned 1 exit status make[1]: *** [Makefile:160: aes/crypt_and_hash] Error 1 make[1]: Leaving directory '/workspaces/mbedtls/programs' make: *** [Makefile:34: programs] Error 2 (venv) dev [ /workspaces/mbedtls ]$ ``` So I have two questions: This error says it fails to link find crt0.o but the output (library/libmbedcrypto.a) exists and looks ok (altho I've yet to try linking against it). Is the error message spurious or is the library it produced unusable? Do I really need a version of crt0.o to link successfully? (The same configuration builds with no errors using the host's x64 compiler toolchain - and that toolchain also doesn't have a crt0.o file). Thanks in advance!

7 months

1
1
0 0

Any plan for a Java Binding ?

by Simon Bernard

Hi, I'm the main developer of Leshan Library. This is a Java open source implementation of LWM2M protocol hosted at Eclipse Foundation. We currently use Scandium (from Californium Project) as DTLS library. This library fits our needs until now but we have some concerns about future-proofness of it (Especially, there is no plan for DTLS 1.3) and there is no support of TLS. So we explore some other way for the future. I had consider to use OpenJdk but there is a lot of missing IoT Features. I contact OpenJdk security dev and they makes me understand politely that IoT is not the priority (at least this is my understanding) Another solution we explore would be to use an mbedtls Java binding. (as mbedtls is well supported and focus IoT) There is a not official one at : https://github.com/open-coap/kotlin-mbedtls *Questions : * 1. Is there any official java binding ? 2. If no, is there any plan for that kind of binding ? 3. If no, if there is a community initiative could it be hosted by you ? Thx, Simon

7 months

2
2
0 0

Invitation: MBed-TLS Technical Forum - Asia @ Every 4 weeks from 10am to 10:50am on Monday (GMT) (mbed-tls@lists.trustedfirmware.org)

by Shaun Longhorn

MBed-TLS Technical Forum - Asia Every 4 weeks from 10am to 10:50am on Monday United Kingdom Time Location https://linaro-org.zoom.us/j/99853938085?pwd=D3au597hb9J1veo1W74pIqkvY6VaDI… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9985393… Join Zoom Meeting https://linaro-org.zoom.us/j/99853938085?pwd=D3au597hb9J1veo1W74pIqkvY6VaDI… Join by phone (US) +1 833-548-0282 passcode: 12278212 Joining instructions https://www.google.com/url?q=https://applications.zoom.us/addon/invitation/… Joining notes Meeting host: shaun.longhorn(a)linaro.org Join Zoom Meeting: https://linaro-org.zoom.us/j/99853938085?pwd=D3au597hb9J1veo1W74pIqkvY6VaDI… ──────────https://linaro-org.zoom.us/j/99853938085?pwd=D3au597hb9J1veo1W74pIqkvY6VaDI.1&jst=2Joining Instructions────────── Guests mbed-tls(a)lists.trustedfirmware.org psa-crypto(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NjI4c3NnYjFoZHRh… Reply for mbed-tls(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NjI4c3NnYjFoZHRh… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

7 months

1
0
0 0

Invitation: MBed-TLS Technical Forum - Asia @ Every 4 weeks from 10am to 10:50am on Monday (BST) (mbed-tls@lists.trustedfirmware.org)

by Shaun Longhorn

MBed-TLS Technical Forum - Asia Every 4 weeks from 10am to 10:50am on Monday United Kingdom Time Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: MBed-TLS Technical Forum - AsiaTime: Jun 16, 2025 10:00 AM London Every 4 weeks on Mon, 39 occurrence(s)Please download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJMqcuGuqDotGtIbACm498ytl0ZhydWKdu1b/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/97758661706?pwd=baMjUvnWbY20z3ignQca7QVahhozkI.1Meeting ID: 977 5866 1706Passcode: 577208---One tap mobile+16892781000,,97758661706# US+17193594580,,97758661706# US---Dial by your location• +1 689 278 1000 US• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• +1 346 248 7799 US (Houston)• +1 360 209 5623 US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558 8656 US (New York)• +1 646 931 3860 US• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• 833 548 0282 US Toll-free• 833 928 4608 US Toll-free• 833 928 4609 US Toll-free• 833 928 4610 US Toll-free• 877 853 5247 US Toll-free• 888 788 0099 US Toll-free• 833 548 0276 US Toll-freeMeeting ID: 977 5866 1706Find your local number: https://linaro-org.zoom.us/u/acdtApJNbc Guests mbed-tls(a)lists.trustedfirmware.org psa-crypto(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NjI4c3NnYjFoZHRh… Reply for mbed-tls(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NjI4c3NnYjFoZHRh… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

7 months

1
0
0 0

Invitation: MBed-TLS Technical Forum - Asia @ Every 4 weeks from 10am to 10:50am on Monday from Mon 21 Apr to Sun 18 May (BST) (mbed-tls@lists.trustedfirmware.org)

by Shaun Longhorn

MBed-TLS Technical Forum - Asia Every 4 weeks from 10am to 10:50am on Monday from Monday 21 Apr to Sunday 18 May United Kingdom Time Location https://linaro-org.zoom.us/j/99853938085?pwd=D3au597hb9J1veo1W74pIqkvY6VaDI… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9985393… Join Zoom Meeting https://linaro-org.zoom.us/j/99853938085?pwd=D3au597hb9J1veo1W74pIqkvY6VaDI… Join by phone (US) +1 833-548-0282 passcode: 12278212 Joining instructions https://www.google.com/url?q=https://applications.zoom.us/addon/invitation/… Joining notes Meeting host: shaun.longhorn(a)linaro.org Join Zoom Meeting: https://linaro-org.zoom.us/j/99853938085?pwd=D3au597hb9J1veo1W74pIqkvY6VaDI… ──────────https://linaro-org.zoom.us/j/99853938085?pwd=D3au597hb9J1veo1W74pIqkvY6VaDI.1&jst=2Joining Instructions────────── Guests mbed-tls(a)lists.trustedfirmware.org psa-crypto(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NjI4c3NnYjFoZHRh… Reply for mbed-tls(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NjI4c3NnYjFoZHRh… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

7 months

1
0
0 0

PQC code from European Project QUBIP - Security Pattern

by Alberto Battistello

Hi all, I am writing in behalf of Security Pattern, a security firm specialized in embedded systems. We are a member of the QUBIP European Funded Project (https://qubip.eu), which aims at transitioning protocols, networks, and systems to Post Quantum algorithms. As a result of the project, we have integrated a set of Post Quantum algorithms in the TLS1.3 stack of the MbedTLS code (see here https://github.com/QUBIP/pq-mqtt-client-mbedtls). We have code running on STM32 Nucleo board in two versions: the former is a full software, by leveraging the crypto primitives provided in a library developed by another partner, the latter using a Secure Element emulated by FPGA connected via I2C (also developed by another partner of QUBIP). Our main work has beed dedicated to integrating the new hybrid KEM and signatures (MLKEM768-x25519 and MLDSA44-Ed25519) into the TLS stack, in order to demonstrate communication with an MQTT broker running OpenSSL. At the current stage we are about to publish the code on github with MIT license (here https://github.com/QUBIP/pq-mqtt-client-mbedtls). Meanwhile, we think the effort we made could be of help for MBedTLS development/developers. So I would like to ask if you can address me to some contact that is responsible in MbedTLS or ARM about the PQC transition or the best way to facilitate the use/integration of our work. Best Regards, Alberto -- Security Pattern <https://www.securitypattern.com/> Alberto Battistello Senior Security Engineer M. +39 333 3239810 Via G. Boccaccio, 58 | 25080 Mazzano (BS) | Italy | P.I. 03943650980 www.securitypattern.com <https://www.securitypattern.com/?utm_source=newsletter&utm_medium=email&utm…> | Follow Linkedin <https://www.linkedin.com/company/securitypattern/> | We value your privacy <https://www.iubenda.com/privacy-policy/40319464/legal>

7 months, 2 weeks

2
1
0 0

handshake fail with "Alert (Level: Fatal, Description: Protocol Version)"

by 扶柏成

Hi all, We have encountered a challenge while using mbedTLS 3.5.1 and would greatly appreciate the assistance of the experts. Thank you in advance for your support. I used mbedTLS 3.5.1 to connect to the server acc.connect.cpms.milence.com, and the TLS handshake failed with an Alert (Level: Fatal, Description: Protocol Version) error. Detailed information is described at this GitHub issue<https://github.com/Mbed-TLS/mbedtls/issues/10141>. * We attempted to connect with the Windows EDGE browser and found through packet capture that the handshake was successful. * We were also able to successfully handshake using TLS 1.2. * When we limited the supported group to only: MBEDTLS_SSL_IANA_TLS_GROUP_SECP256R1 and used TLS 1.3, the handshake was also successful. For more details, please refer to the discussion on GitHub: Handshake fail with "Alert (Level: Fatal, Description: Protocol Version)" ・ Issue #10141 ・ Mbed-TLS/mbedtls<https://github.com/Mbed-TLS/mbedtls/issues/10141>. Best Regards, Fu Baicheng

8 months

1
0
0 0

Mbed TLS 3.6.3 and 2.28.10

by Minos Galanakis

Dear Mbed TLS users, We have released Mbed TLS versions 3.6.3 and 2.28.10. These releases provide bugfixes, security fixes and minor improvements. This release of Mbed TLS provides the fix for the TLS compatibility issue of handling fragmented handshake messages. This release includes fixes for security issues. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-2.28.10 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.3 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Many thanks, Minos Galanakis Mbed TLS developer

9 months

1
0
0 0

[Mbed-tls-announce] Mbed TLS 3.6.3 and 2.28.10

by Minos Galanakis via Mbed-tls-announce

Dear Mbed TLS users, We have released Mbed TLS versions 3.6.3 and 2.28.10. These releases provide bugfixes, security fixes and minor improvements. This release of Mbed TLS provides the fix for the TLS compatibility issue of handling fragmented handshake messages. This release includes fixes for security issues. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-2.28.10 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.3 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Many thanks, Minos Galanakis Mbed TLS developer IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

9 months

1
0
0 0

[Mbed-tls-announce] Announcing Mbed TLS 3.6.3 and 2.28.10

by Gilles Peskine via Mbed-tls-announce

Dear Mbed TLS users, The next release of Mbed TLS (3.6.3 and 2.28.10) is scheduled on Monday 2025-03-24. It will include a security fix for a vulnerability with a high impact to affected applications. Due to the nature of the vulnerability, which involves an insecure default in current versions of Mbed TLS, fixing it may require a small change in application code. We will provide instructions in the release notes. Without this change, affected applications will fail at runtime with Mbed TLS 3.6.3 or 2.28.10. Applications that are currently secure will generally not require any change. We apologize for the inconvenience. Best regards, -- Gilles Peskine On behalf of the Mbed TLS security team IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

9 months, 1 week

1
0
0 0

Inquiry about the ECC-160 bit size support in MbedTLS

by Ankita Hatmode

Hi Team, I am working on an embedded security project and exploring ECC support in MbedTLS 3.6.2. I would like to confirm whether the MbedTLS supports ECC-160 i.e. Elliptic Curve Cryptography with a 160 bit key size, in the latest version or any earlier versions. Looking forward to your response. Thanks and regards, Ankita Hatmode -- ------------------------------------------------------------------------------------------------------------------------- **Disclaimer:** This email message including any attachments is confidential, and may be privileged and proprietary to Agiliad. If you are not the intended recipient, please notify us immediately by replying to this message and destroy all copies of this message including any attachments. You are NOT authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. Thank you. ------------------------------------------------------------------------------------------------------------------------

9 months, 2 weeks

3
2
0 0

Problem during test_suite generation while cross-compiling on version 3.6.2

by Francois Mace

Hello Everybody, I am trying to migrate my cross-compilation setup from version 2.28.9 to version 3.6.2. I use a Makefile based approach for compilation. Everything seems to work fine up to the point where the compilation process reaches the test_suite data generation Gen suites/test_suite_psa_crypto_generate_key.generated.data suites/test_suite_psa_crypto_low_hash.generated.data suites/test_suite_psa_crypto_not_supported.generated.data suites/test_suite_psa_crypto_op_fail.generated.data suites/test_suite_psa_crypto_storage_format.current.data suites/test_suite_psa_crypto_storage_format.v0.data At that point it seems that the python based tools attempts to execute a temp executable (generated for my cross-compilation target ?) which fails. The traceback obtained is the following: Traceback (most recent call last): File "../framework/scripts/generate_psa_tests.py", line 849, in <module> test_data_generation.main(sys.argv[1:], __doc__, PSATestGenerator) File "/home/dev/test/mbed-TLS_3.6.2/framework/scripts/mbedtls_framework/test_data_generation.py", line 224, in main generator.generate_target(target) File "../framework/scripts/generate_psa_tests.py", line 845, in generate_target super().generate_target(name, self.info) File "/home/dev/test/mbed-TLS_3.6.2/framework/scripts/mbedtls_framework/test_data_generation.py", line 177, in generate_target self.write_test_data_file(name, test_cases) File "/home/dev/test/mbed-TLS_3.6.2/framework/scripts/mbedtls_framework/test_data_generation.py", line 164, in write_test_data_file test_case.write_data_file(filename, test_cases) File "/home/dev/test/mbed-TLS_3.6.2/framework/scripts/mbedtls_framework/test_case.py", line 88, in write_data_file for tc in test_cases: File "../framework/scripts/generate_psa_tests.py", line 694, in all_test_cases if key.location_value() != 0: File "/home/dev/test/mbed-TLS_3.6.2/framework/scripts/mbedtls_framework/psa_storage.py", line 186, in location_value return self.lifetime.value() >> 8 File "/home/dev/test/mbed-TLS_3.6.2/framework/scripts/mbedtls_framework/psa_storage.py", line 89, in value self.update_cache() File "/home/dev/test/mbed-TLS_3.6.2/framework/scripts/mbedtls_framework/psa_storage.py", line 67, in update_cache include_path=includes) #type: List[str] File "/home/dev/test/mbed-TLS_3.6.2/framework/scripts/mbedtls_framework/c_build_helper.py", line 158, in get_c_expression_values output = subprocess.check_output([exe_name]) File "/usr/lib/python3.7/subprocess.py", line 395, in check_output **kwargs).stdout File "/usr/lib/python3.7/subprocess.py", line 472, in run with Popen(*popenargs, **kwargs) as process: File "/usr/lib/python3.7/subprocess.py", line 775, in __init__ restore_signals, start_new_session) File "/usr/lib/python3.7/subprocess.py", line 1522, in _execute_child raise child_exception_type(errno_num, err_msg, err_filename) OSError: [Errno 8] Exec format error: '/tmp/tmp--m95sjmdw' make[2]: *** [Makefile:127: generated_psa_test_data] Error 1 make[2] : on quitte le répertoire « /home/dev/test/mbed-TLS_3.6.2/tests » make[1]: *** [Makefile:35: tests] Error 2 make[1] : on quitte le répertoire « /home/dev/test/mbed-TLS_3.6.2 » make: *** [test.make:152: all] Error 2 Looking at the format of the generated tmp executable, it seems it is generated for my cross-compilation target, it therefore cannot be executed in my compilation environment. I would like to be able to generate the test and test data in order to be able to execute them on my compilation target, which is what I used to do with the previously integrated version of the library. Is there something I am missing in my compilation? am I missing a specific setup variable in my Makefile? Thanks for your feedback. Best regards, Francois

10 months

2
1
0 0

Different performance from 2.6.2 to 3.6.2 for https file upload

by Stefano Tebaldi

Hello, I recently updated mbedTLS library version 2.6.2 to 3.6.2. I am using the library to add https to Mongoose web server on a STM32H753 with FreeRTOS + LWIP. 2.6.2 was generated in a IAR project using STMCubeMX. What I am noticing is that file transfer performance has gotten much worse. With version 2.6.2 it took a few minutes to transfer a file of around 33 MB, now with version 3.6.2 it takes around 15 min. What could this depend on? Attached is the configuration used for the two versions. The certificate for https is EC curve secp256r1. Thank you

10 months

2
4
0 0

[Mbed-tls-announce] Mbed TLS 4.0/TF-PSA Crypto 1.0 release timeline

by Janos Follath via Mbed-tls-announce

Dear Mbed TLS and PSA Crypto users, We would like to update you on the release timeline for Mbed TLS 4.0/TF-PSACrypto1.0 release. As a reminder, the key objectives of the release are a separate TF-PSA Crypto repo., PSA Crypto becoming the de facto Crypto API and Mbed TLS using PSA Crypto APIs as the crypto API by default. While TF-PSA Crypto repository is now available, the remaining effort to be ready for the release is more than we originally planned for. Based on remaining effort estimates, we plan to make Mbed TLS 4.0-Beta and TF-PSA Crypto 1.0-Beta release around end of June. The Mbed TLS 4.0, and TF-PSA Crypto 1.0 release is expected around end of September. We don’t expect users to integrate the Beta release. Beta is aimed to pipeclean the separate Mbed TLS and TF-PSA Crypto release process and get any early feedback. The release in September is expected to be integrated by users to their projects. We wanted to provide these revised release dates so that the users can plan accordingly. In the meantime, bug fixes and security fixes will continue to be provided via. Mbed TLS 3.6.x LTS releases. Thanks, Mbed TLS/PSA Crypto Maintainers. -- Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

10 months, 2 weeks

1
0
0 0

Support for Quantum Safe Algorithms

by NAYNA JAIN

Hi MbedTLS team, I have been following up the MbedTLS roadmap from here - https://mbed-tls.readthedocs.io/en/latest/project/roadmap/ . It talks about Post Quantum Cryptography support in future. And in the section of Long Term Plans for MbedTLS, I see the note related to PQC as "Regarding post-quantum cryptography (PQC) in particular, we do plan to wait until there are official standards: as of 2023, apart from stateful hash-based signatures, there are too many open questions about selected algorithms (choice of parameters, data formats, hybrid combinations…). This note seems to be pretty old as it refers to 2023.. So, are there any latest update on the roadmap? Is there any plan to support latest NIST standardized algorithms (ML-DSA, ML-KEM, SLH-DSA) in this year or next year. Thanks & Regards, * Nayna

10 months, 3 weeks

3
2
0 0

Using mbedTLS for TLS&X509 with a separate PSA Crypto Implementation

by Zak, Kevin

Hello mbedtls mailing list, I'm working to modify mbedTLS (3.6.2) to use our PSA Crypto Implementation in a separate library. Our solution does not make use of PSA 'drivers' that mbedTLS refers to. I've modified makefiles to not build PSA Crypto files, and have enabled MBEDTLS_PSA_CRYPTO_C & MBEDTLS_USE_PSA_CRYPTO. I've also defined MBEDTLS_PSA_ACCEL_ALG_XXX for our supported algorithms. 1. Is there a good way to determine whether a given TLS/X509 configuration would require a certain 'legacy' (maybe a better term is 'non-PSA') crypto file to be built into the mbedTLS library? * The goal is to build as few crypto source files into the mbedTLS source files as possible, maximizing usage of our separate PSA implementation 2. Example: My test application using mbedtls_x509_crt_parse() receives linking errors for mbedtls_ecp_(group/point)_xxx() and mbedtls_mpi_xxx() that are referenced in pkparse.c (which I am building into the library). * Ecp.c is currently excluded from the build (as is its define) - if I add it, I add significantly more linking errors for mbedtls_mpi APIs. I was under the impression that ECP and MPI APIs could be avoided with the correct configuration. * If ecp/mpi helper APIs are needed still for x509, this would be good to know. However, I'd like to avoid usage of MPI APIs that perform actual software calculations. See the screenshot for a list of non-PSA crypto files I am currently building to test with. I imagine I may have to add more incrementally. [cid:image001.png@01DB726D.879014D0] Any insights on this general use case or my ECP troubles with x509 would be appreciated. I plan to extend the strategy as these are the findings from an attempt to use just one x509 API. Best, Kevin Zak

10 months, 3 weeks

2
1
0 0

Use mbedtls_gcm_auth_decrypt get wrong tag

by Elva Huang

Dear mbed TLS team, Recently, while debugging my code, I encountered an issue when using the AES-GCM algorithm. I found that when calling the mbedtls_gcm_auth_decrypt interface in version 3.6.1, the calculated tag consistently does not match the input tag. However, when using the same interface in version 2.28.2, the tag is successfully calculated as expected. Below is the demo code we are using: tstSecKeyList g_stPreInterKey = { .u8KeyNum = 5U, .u8IsUse = 1U, .u16KeyLen = 16U, .u16IVLen = 12U, .u16AddLen = 16U, .enuSecType = SEC_AES_GCM, .au8Key = { 0x68U, 0xffU, 0xb7U, 0xffU, 0x5eU, 0xffU, 0x10U, 0xffU, 0x9eU, 0xffU, 0xb8U, 0xffU, 0x01U, 0xffU, 0xb9U, 0xffU, 0xa0U, 0xffU, 0x1cU, 0xffU, 0xdfU, 0xffU, 0x0aU, 0xffU, 0xe6U, 0xffU, 0xc8U, 0xffU, 0xc5U, 0xffU, 0x39U, 0xffU }, .au8Iv = { 0x3, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x0, 0x1, 0x2, 0x3 }, .au8Add = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 } .u16AddLen = 0, }; static uint8_t s_au8SecMemoryBuffer[6*1024]; mbedtls_gcm_context aesGcmContext; uint8_t *pau8EncryptedPlain = inParam0; (note: inParam0=434421d30c9abf31b96d2d28d00b5cb4e6fe84033999d53d3a50674b3aedd81f) uint8_t *pau8AesTag = inParam0 + 16; (e6fe84033999d53d3a50674b3aedd81f) uint8_t u8EncryptedPlainLen = 16; uint8_t u8AesTagKeyLen = 16; mbedtls_gcm_init(&aesGcmContext); mbedtls_memory_buffer_alloc_init(s_au8SecMemoryBuffer, 6*1024); vidPreInterKeyget(g_stPreInterKey.au8Key, au8preInterKey); mbedtls_gcm_setkey(&aesGcmContext, MBEDTLS_CIPHER_ID_AES, au8preInterKey, 16*8); s32Ret = mbedtls_gcm_auth_decrypt(&aesGcmContext, u8EncryptedPlainLen, g_stPreInterKey.au8Iv, g_stPreInterKey.u16IVLen, g_stPreInterKey.au8Add, g_stPreInterKey.u16AddLen, pau8AesTag, u8AesTagKeyLen, pau8EncryptedPlain, s_au8DecryptKey); Best regards,

11 months

1
1
0 0

Question Regarding Change Cipher Spec States in the TLS 1.3 Handshake Protocol

by 千山啼祢

Dear Developer, I was reviewing the code and noticed that in the TLS 1.3 handshake protocol state machine, the "Change Cipher Spec" state has been divided into five different states based on its occurrence timing. Could you please clarify if there are any specific considerations for this approach? Additionally, these states can appear multiple times during a single handshake, which implies multiple "Change Cipher Spec" messages. However, the TLS 1.3 standard suggests that the "Change Cipher Spec" should only appear once in a single handshake. Could you kindly explain the rationale behind this design decision? Thank you for your time and assistance. I look forward to your response. Best regards, XiangDong Li

11 months, 2 weeks

1
0
0 0

Inquiry Regarding mbedTLS v2.16.2 Compatibility for Secure MQTT Connection on STM32CubeIDE

by Noushad

Hello, I am currently working on a project using STM32CubeIDE, where I am leveraging mbedTLS v2.16.2 to establish a secure MQTT connection with a Mosquitto broker on port 8883. During my implementation, I encountered a TLS handshake error with the following details: mbedtls_ssl_handshake failed. -29312 (-0x7280) I would like to confirm if mbedTLS v2.16.2, as provided in STM32CubeIDE, supports secure TLS connections (e.g., Secure MQTT) and is compatible with Mosquitto broker configurations. Additionally, I would appreciate guidance on resolving this error. Here are some specific details about my setup: 1. mbedTLS version: 2.16.2 (as integrated into STM32CubeIDE). 2. Broker: Mosquitto, configured for secure MQTT on port 8883. 3. Issue: TLS handshake fails with the error mentioned above. 4. Certificates: [CA certificates, ]. Please let me know if additional information Regards, Noushad Embedded systems engineer Inthings Technologies Private Limited www.inthings.tech<http://www.inthings.tech> [cid:image001.png@01DB65BA.1F5B9660]

11 months, 2 weeks

1
0
0 0

Question Regarding Change Cipher Spec States in the TLS 1.3 Handshake Protocol

by 千山啼祢

Dear Developer, I was reviewing the code and noticed that in the TLS 1.3 handshake protocol state machine, the "Change Cipher Spec" state has been divided into five different states based on its occurrence timing. Could you please clarify if there are any specific considerations for this approach? Additionally, these states can appear multiple times during a single handshake, which implies multiple "Change Cipher Spec" messages. However, the TLS 1.3 standard suggests that the "Change Cipher Spec" should only appear once in a single handshake. Could you kindly explain the rationale behind this design decision? Thank you for your time and assistance. I look forward to your response. Best regards, XiangDong Li

11 months, 2 weeks

1
0
0 0

Heap and stack usage information

by Michael Thomas

Hi, I am trying to determine what would be an optimal stack and heap allocation for mbedtls. I realize this changes with algorithms, some configuration macros for the algorithms as well as concurrency. But is there any information on stack and heap usage that I can use as a starting point? And is there any information on the same for a crypto suite. Thanks Michael T Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not an intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you.

11 months, 2 weeks

1
0
0 0

Inquiry Regarding mbedTLS v2.16.2 Compatibility for Secure MQTT Connection on STM32CubeIDE

by Noushad

Hello, I am currently working on a project using STM32CubeIDE, where I am leveraging mbedTLS v2.16.2 to establish a secure MQTT connection with a Mosquitto broker on port 8883. During my implementation, I encountered a TLS handshake error with the following details: mbedtls_ssl_handshake failed. -29312 (-0x7280) I would like to confirm if mbedTLS v2.16.2, as provided in STM32CubeIDE, supports secure TLS connections (e.g., Secure MQTT) and is compatible with Mosquitto broker configurations. Additionally, I would appreciate guidance on resolving this error. Here are some specific details about my setup: 1. mbedTLS version: 2.16.2 (as integrated into STM32CubeIDE). 2. Broker: Mosquitto, configured for secure MQTT on port 8883. 3. Issue: TLS handshake fails with the error mentioned above. 4. Certificates: [Specify if you are using self-signed certificates, CA certificates, etc.]. Please let me know if additional information or logs would be helpful for diagnosing the issue. Thank you for your assistance. Regards, Noushad Embedded systems engineer Inthings Technologies Private Limited www.inthings.tech<http://www.inthings.tech> [cid:image001.png@01DB5D28.96B30030] Regards, Noushad Embedded systems engineer Inthings Technologies Private Limited www.inthings.tech<http://www.inthings.tech> [cid:image001.png@01DB5D28.96B30030]

11 months, 3 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

mbed-tls