- mbed-tls - lists.trustedfirmware.org

by David Horstmann

Dear Mbed TLS users, We have released Mbed TLS versions 3.6.1 and 2.28.9. These releases provide bugfixes, security fixes and minor improvements. The 3.6.1 release includes fixes for issues caused by enabling TLS 1.3 for TLS connections in the default configuration. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-2.28.9 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.1 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Many thanks, David Horstmann Mbed TLS developer

2 years

1
0
0 0

Mbed TLS 4.0 roadmap and bignum/ecp API

by Gernot Kvas

Hi all, From the announcement and also the long term plans (https://mbed-tls.readthedocs.io/en/latest/project/long-term-plans/) it is apparent that bignum/ecp operations on the public API will go away and usage will be restricted to internal only. I do understand and welcome the shift towards PSA API and to abandon the ALT interface for higher level legacy API crypto functions. However, I'm not so positive about removal of the bignum and ecp API. There are projects using those functions even in their PSA porting layer (Matter comes to mind: https://github.com/project-chip/connectedhomeip/blob/master/src/crypto/CHIP…) or projects using the bignum layer as abstraction (Zephyr hostap/wpa_supplicant: https://github.com/zephyrproject-rtos/hostap/tree/main/src/crypto, crypto_mbedtls*.c). There might be a case to support those functions to have (hardware-accelerated) low level building blocks for algorithms Mbed TLS doesn't yet or never will support. As other SSL libraries such as OpenSSL also expose similar API (BN_ and EC_POINT_ ), the removal in Mbed TLS will certainly leave a gap. What's the view here from the project team? Cheers, Gernot

2 years

2
1
0 0

Requesting information for mbed-tls commercial license & support

by Kumar, Praveen

Hi, We are in the process of qualifying a suitable encryption library for our pre-hospital patient monitor and the telemedicine system. I am writing to request your guidance regarding the mbed-tls use for commercial purposes. I look forward to your response. Regards, Praveen Kumar R&D Project Manager Emergency Care Professional (EC-Pro) Philips Tel +44 (0) 1256 362427 Email praveen.m.kumar(a)philips.com<mailto:praveen.m.kumar@philips.com> Remote Diagnostic Technologies Limited. Registered office: Ascent 1, Farnborough Aerospace Centre, Aerospace Boulevard, Farnborough GU14 6XW, UK. Registered in England No. 3321782. [Logo Description automatically generated]<http://www.philips.com/> Connect with Philips [cid:image002.gif@01DAE7F8.0802FC50]<https://www.linkedin.com/company/philips/>[cid:image003.gif@01DAE7F8.0802FC50]<https://twitter.com/PhilipsHealth>[cid:image004.gif@01DAE7F8.0802FC50]<https://www.youtube.com/PhilipsHealthcare/videos> ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

2 years

3
6
0 0

Major changes in Mbed TLS 4.0

by Gilles Peskine

Hello, Following consultations with the community and internal discussions among the Mbed TLS maintenance team, we can now present the major changes that will happen in the next major version of Mbed TLS. Our plan remains to release in the second quarter of 2025. The next major version will focus on two things: 1. The cryptography library will be a separate product called TF-PSA-Crypto 1.0. The X.509 and TLS library will be called Mbed TLS 4.0, and will rely on TF-PSA-Crypto for all cryptographic functionality. 2. This release completes the migration of cryptography APIs from classic mbedtls APIs to PSA APIs. Please find more information below about what this means in practice. What follows are just headlines, not an exhaustive list of changes. We expect many small changes that do not affect major functionality. Please note that the changes presented here are our current plan. We may revise it based on new inputs, new insights or unexpected hurdles. You can follow the advancement of the design, planning and development of the next release on the 4.0+1.0 planning board at https://github.com/orgs/Mbed-TLS/projects/15/views/1 . Removal of legacy APIs The following low-level application interfaces will no longer be present in the API of TF-PSA-Crypto 1.0 and Mbed TLS 4.0: * Hashes: hkdf.h, md5.h, ripemd160.h, sha1.h, sha3.h, sha256.h, sha512.h; * Random generation: ctr_drbg.h, hmac_drbg.h, entropy.h; * Ciphers and modes: aes.h, aria.h, camellia.h, chacha20.h, chachapoly.h, cipher.h, cmac.h, gcm.h, poly1305.h; * Private key encryption mechanisms: pkcs5.h, pkcs12.h. * Asymmetric cryptography: bignum.h, dhm.h, ecdh.h, ecdsa.h, ecjpake.h, ecp.h, rsa.h. The cryptographic mechanisms remain present, but they will only be accessible via the PSA API (psa_xxx functions introduced gradually starting with Mbed TLS 2.17). If you maintain code that uses these interfaces, you can already start migrating it today, since almost all PSA interfaces are available in the mbedtls-3.6 long-time support branch (and many even in 2.28 LTS). Please consult the PSA transition guide https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-3.6/docs/psa-transition.md for guidance. Some non-PSA crypto interfaces will still be present in TF-PSA-Crypto 1.0: * pk.h will remain with some changes, mainly to provide an interface to key parsing and formatting which does not have a PSA equivalent yet. * md.h will remain as a thin layer over PSA hash functions (not HMAC) to ease the transition. * nist_kw.h will remain because it does not have a PSA equivalent yet. Removal of legacy integration interfaces TF-PSA-Crypto 1.0 and Mbed TLS 4.0 will no longer support MBEDTLS_xxx_ALT replacement of functions and modules. Use PSA transparent drivers instead. TF-PSA-Crypto 1.0 and Mbed TLS 4.0 will no longer support MBEDTLS_PK_RSA_ALT and MBEDTLS_PSA_CRYPTO_SE_C. Use PSA opaque drivers instead. TF-PSA-Crypto 1.0 and Mbed TLS 4.0 will no longer have the mbedtls/entropy.h interface to configure entropy sources. This will be replaced by PSA random drivers. In addition, we are planning to rework the platform abstraction layer (MBEDTLS_PLATFORM_xxx configuration options). More details will be available in the coming months. Removal of legacy mechanisms The following cryptographic mechanisms are planned to be removed in TF-PSA-Crypto 1.0 and Mbed TLS 4.0: * DES (including 3DES). * PKCS#1v1.5 encryption/decryption (RSAES-PKCS1-v1_5). (OAEP, PSS, and PKCS#1v1.5 signature are staying.) * Finite-field Diffie-Hellman with custom groups. (RFC 7919 groups remain supported.) * Elliptic curves of size 225 bits or less. The following cipher suites are planned to be removed from (D)TLS 1.2 in Mbed TLS 4.0: * TLS_RSA_* (including TLS_RSA_PSK_*), i.e. cipher suites using RSA decryption. (RSA signatures, i.e. TLS_ECDHE_RSA_*, are staying.) * TLS_ECDH_*, i.e. cipher suites using static ECDH. (Ephemeral ECDH, i.e. TLS_ECDHE_*, is staying.) * TLS_DHE_*, i.e. cipher suites using finite-field Diffie-Hellman. (Ephemeral ECDH, i.e. TLS_ECDHE_*, is staying.) * TLS_*CBC*, i.e. all cipher suites using CBC. Non-functional changes Due to the separation into two separate products (TF-PSA-Crypto and Mbed TLS), there will be major changes to the directory structure and to the build system. We plan to use CMake as the primary build system. Since TF-PSA-Crypto is a new product, identifiers that are not PSA interfaces (such as optimisation options and platform interfaces) will be renamed with a new prefix. Best regards, -- Gilles Peskine Mbed TLS developer

2 years

3
4
0 0

Usage of ECB in AES mode

by Chaitanya Tata

Hi, ECB is unsecure, see https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_cod… and shouldn't be used in production. So, I have switched to one of CBC/CMAC/CTR modes, but in `mbedtls_cipher_cmac_starts` I see that it only accepts ECB variants, and also doesn't seem to be using the `type`. From https://github.com/Mbed-TLS/mbedtls/issues/8617 I see that ECB for AES was intentional, even for the CMAC API. Is this expected? 1. Is using ECB for CMAC API correct? 2.Shouldn't we remove the ECB altogether? Appreciate any clarifications. Cheers, Chaitanya.

2 years

2
4
0 0

[Hyosung TNS] Request a quote for embedded encryption library

by SHIN JAE WHAN(신재환)

Dear Trusted Firmware, I’m Jay, an embedded security firmware developer at Hyosung TNS<https://global.hyosunginnovue.com/?lang_switch>. We are a company that manufactures ATMs. For cryptographic communication between ATM PC software and ATM devices, we are looking for a cryptographic library to apply to ATM devices(e.g. cash dispenser). If there is an appropriate library that meets the requirements below, I would appreciate it if you could provide us an estimate. If custom development is required, I would also like to know the expected development period. [Development environment] - CPU : TI AM1806(ARM9) - Compiler : ARM DS-5(armcc) - RTOS : ThreadX - C language - No dynamic allocation - VFP(Vectored Floating Point) not supported [Security Features] - RSA(2048bits) : Certificate and signature verification, Data encryption and decryption - ECC(256bits) : Generating a symmetric key using ECDH and ECDSA - 3DES, AES, AEAD, SHA256, HMAC256, etc : Algorithms related to data encryption and decryption - Random : Prevent replay attacks Please contact me if you have any questions. Best Regards, Jay [cid:image001.png@01DAE289.1B3D4C90] Jaewhan Shin Performance Manager | CISSP | Firmware Development Team Suseo Bldg., 281, Gwangpyeong-ro, Gangnam-gu, Seoul, 06349 Korea t. 82-2-6181-2480, m. 82-10-8158-3015 e. jaewhan.shin(a)hyosung.com<mailto:jaewhan.shin@hyosung.com> hyosunginnovue.com<https://hyosunginnovue.com/> [cid:image002.png@01DAE289.1B3D4C90]<https://www.linkedin.com/company/hyosung-tns/> [cid:image003.png@01DAE289.1B3D4C90] <https://www.youtube.com/@hyosungtns3918> HYOSUNG TNS, Inc. Email Disclaimer. This communication, including attachments, is intended only for the exclusive use of addressee and may contain proprietary, confidential, or privileged information. Any use, review, duplication, disclosure, dissemination, or distribution is strictly prohibited. If you were not the intended recipient, and you have received this communication in error, please notify sender immediately by return e-mail, delete this communication, and destroy any copies.

2 years, 1 month

1
0
0 0

TLS 1.3 failures in Mbed TLS 3.6.0

by Gilles Peskine

Hello, Mbed TLS 3.6.0 was the first release to enable TLS 1.3 support by default. Unfortunately, this breaks many applications that open a TLS connection with default settings, which are now negotiating TLS 1.3 instead of TLS 1.2, but hit a difference in how Mbed TLS 3.6.0 implements the two versions of the protocol. The most common symptom is: you are using the default configuration (or something close), and your application fails in the handshake with an internal error whenever it negotiates TLS 1.3. To resolve this, call psa_crypto_init() before starting a TLS handshake. For a list of other known issues, please see https://github.com/Mbed-TLS/mbedtls/issues/9223 If you are encountering a problem due to the enablement of TLS 1.3 that is not listed on that page, please let us know by opening an issue on GitHub. If no workaround or patch is available for your problem yet, you can disable TLS 1.3 by calling mbedtls_ssl_conf_max_tls_version(ssl_config, MBEDTLS_SSL_VERSION_TLS1_2) before mbedtls_ssl_setup(). We are planning to fix all the issues listed on that page before the 3.6.1 patch release. We do not yet have a date for the 3.6.1 release. Best regards, -- Gilles Peskine Mbed TLS developer

2 years, 1 month

2
1
0 0

TLS-Exporter in TLS 1.3

by Maximilian Fillinger

Hello! I am trying to add TLS 1.3 support to OpenVPN when using Mbed TLS as the TLS library. My current roadblock is that OpenVPN needs the TLS-Exporter functionality (RFC 8446, Section 7.5). For TLS 1.2, we get the master secret through mbedtls_ssl_set_export_keys_cb() and then implement the exporter using mbedtls_ssl_tls_prf(). For TLS 1.3, an approach like this doesn't work because the callback isn't called with the exporter master secret. Am I missing anything, or does this feature not yet exist? Are there any plans to add it? If not, I'd be interested in trying to make a patch. Best regards, Max

2 years, 1 month

2
1
0 0

bestwritercontent

by hma3yf39＠mediaholy.com

https://www.bestwritercontent.com A man was going to the house of some rich person. As he went along the road, he saw a box of good apples at the side of the road. He said, "I do not want to eat those apples; for the rich man will give me much food; he will give me very nice food to eat." Then he took the apples and threw them away into the dust. He went on and came to a river. The river had become very big; so he could not go over it. He waited for some time; then he said, "I cannot go to the rich man's house today, for I cannot get over the river." He began to go home. He had eaten no food that day. He began to want food. He came to the apples, and he was glad to take them out of the dust and eat them.

2 years, 1 month

1
0
0 0

[Mbed-tls-announce] Requests for feedback about Mbed TLS 4: summary

by Gilles Peskine via Mbed-tls-announce

Hello, In the past few weeks, we have sent a number of requests for feedback on the mbed-tls mailing list about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4.0). Most are about features that we may remove because we think they are not used much and are not worth maintaining. This message is a summary of the requests. If you have concerns about any of these topics, please reply on the GitHub issue (preferred), or on the mbed-tls mailing list, or by private email. (If you reply privately, we will anonymize before sharing outside Arm.) Please reply before 31 July so that we have time to plan 4.0 preparation. While we won't ignore later replies, they will be harder to accommodate. List archive: https://lists.trustedfirmware.org/archives/search?count=25&q=feedback&page=… GitHub links — cryptographic mechanisms https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/102 — Custom ECC mechanisms https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/104 — Custom RSA mechanisms https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/105 — Import of incomplete RSA private keys https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/107 — Direct access to CTR_DRBG and HMAC_DRBG https://github.com/Mbed-TLS/mbedtls/issues/8459 — RSA PKCS#1v1.5 encryption https://github.com/Mbed-TLS/mbedtls/issues/9164 — DES (including 3DES) GitHub links — cryptography implementations https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/103 — Partial ECC acceleration https://github.com/Mbed-TLS/mbedtls/issues/8151 — Dynamically registered secure element drivers GitHub links — TLS 1.2 https://github.com/Mbed-TLS/mbedtls/issues/5278 — FFDH in TLS 1.2 https://github.com/Mbed-TLS/mbedtls/issues/8170 — RSA decryption cipher suites (RSA without DH/ECDH) https://github.com/Mbed-TLS/mbedtls/issues/9201 — Static ECDH cipher suites https://github.com/Mbed-TLS/mbedtls/issues/9202 — CBC cipher suites <https://github.com/Mbed-TLS/mbedtls/issues/9201> GitHub links — platform https://github.com/Mbed-TLS/mbedtls/issues/8108 — Platform interface redesign https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/106 — Building with plain make or CMake https://github.com/Mbed-TLS/mbedtls/issues/8231 — x86_64: AESNI without compiler intrinsics https://github.com/Mbed-TLS/mbedtls/issues/9307 — Support for %zu in printf If you have an opinion on a topic where we haven't requested feedback, you can find our (rapidly evolving) planning board at https://github.com/orgs/Mbed-TLS/projects/15/views/1 . As a reminder, the main focus of the release will be that all cryptography goes through PSA APIs. Low-level legacy cryptography APIs (bignum.h, rsa.h, aes.h, etc.) will no longer be public. Except as indicated here, we generally intend feature parity, but it's possible that we've missed some unusual scenario, so please let us know if you have concerns. Best regards, -- Gilles Peskine 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

2 years, 1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls