- mbed-tls - lists.trustedfirmware.org

Announcing the joint release of Mbed TLS 4.0.0 & TF-PSA-Crypto 1.0.0

by Minos Galanakis

Hi Mbed TLS users, We’re pleased to announce a major milestone: the joint release of Mbed TLS 4.0.0 and the first-ever TF-PSA-Crypto 1.0.0. Mbed TLS now uses PSA Crypto as the default cryptographic API, and these releases include significant API changes that break backward compatibility with previous versions These releases include significant API changes that break backward compatibility with previous versions, so please test your integration thoroughly and follow the migration guides to update your codebase: https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-4.0.0/docs/4.0-migration-g… https://github.com/Mbed-TLS/TF-PSA-Crypto/blob/v1.0.0/docs/1.0-migration-gu… Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.0.0 https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.0.0.

2 months

1
0
0 0

Mbed TLS 3.6.5 Released

by Minos Galanakis

Hi Mbed TLS users, We have released Mbed TLS version 3.6.5. These releases of Mbed TLS address several security issues, provide bug fixes, and bring other minor changes. Full details are available in the release notes https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.5. We recommend all users to consider whether they are impacted, and to upgrade appropriately.

2 months

1
0
0 0

Modernizing a ecdh exchange

by Dirk-Willem van Gulik

I am currently doing an ECDH exchange over MQTT (i.e. at the message layer; MQTT is fundamentally `untrusted') - with a bit of out of band work to confirm end to end integrity. That worked nicely (and interoperable with java-bouncy-castle and openssl, etc with: mbedtls_ecp_group_load( &ctx_cli.grp, MBEDTLS_ECP_DP_CURVE25519 ) mbedtls_ecdh_gen_public( &ctx_cli.grp, &ctx_cli.d, &ctx_cli.Q, mbedtls_ctr_drbg_random, &ctr_drbg) mbedtls_mpi_write_binary( &ctx_cli.Q.X, node_publicsession, 32 ) to create the keys and with mbedtls_mpi_lset( &ctx_cli.private_Qp.Z, 1 )) mbedtls_mpi_read_binary( &ctx_cli.private_Qp.X, pubencr_tmp, CURVE259919_KEYLEN)) mbedtls_ecdh_compute_shared( &ctx_cli.grp, &ctx_cli.private_z, &ctx_cli.private_Qp, &ctx_cli.private_d, mbedtls_ctr_drbg_random, &ctr_drbg ) mbedtls_mpi_write_binary( &ctx_cli.private_z, sessionkey, CURVE259919_KEYLEN) to calculate the emphemeral session key. With the mbedtls_ecdh_context going increasingly private; I assume I can change the latter with: mbedtls_ecdh_calc_secret(&ctx_cli, &len_sessionkey, sessionkey, sizeof(sessionkey), mbedtls_ctr_drbg_random, &ctr_drbg) but am struggling to see how I an replace the key generation itself. Is there a similar option that does not look `into' ctx_cli ?? With kind regards, Dw. PS: actual code at https://github.com/MakerSpaceLeiden/AccesSystem/blob/master/lib-arduino/ACN…

2 months, 2 weeks

1
0
0 0

DTLS handshake with and without hello verify request

by Ankita Hatmode

Hi Team, I am working on exploring DTLS handshake using the mbedtls-3.6.4 version on our embedded platform. I enabled the hello verify request feature and got stuck at hello verify request state on server side if I don't reset the ssl context and don't set the client transport ID. I want to know if there is any way to complete a handshake by bypassing the reset of ssl context and setting the client transport ID. Also, our environment only supports C89 constructs. I could not see inttypes.h in the mbedtls-3.6.4, is there any specific reason to remove this file? I am getting compilation errors without inttypes.h and stdint.h. Is there any macro to be enabled to support the c89 compilation in mbedtls stack? 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. ------------------------------------------------------------------------------------------------------------------------

3 months, 1 week

2
3
0 0

TLS 1.3 and brainpool curves

by Maren Konrad

Dear MbedTLS maintainers, we are already using MBedTLS, however, we recently enabled TLS 1.3 and found that our certificates doesn't work anymore, because they are brainpoolP256r1 (https://datatracker.ietf.org/doc/html/rfc8734). So the question would be, if I missed any configuration to enable the usage of brainpool curves (which are working for TLS 1.2) or if there are any plans, that these are getting supported by MBedTLS 3.6.x? Best regards, Maren Konrad

3 months, 1 week

3
2
0 0

TLS handshake error : unexpected eof

by kavitha bk

Hi We migrated from mbedtls 2.28 to mbedtls 3.6.2 https://github.com/Mbed-TLS/mbedtls/tree/107ea89daaefb9867ea9121002fbbdf926… and we see TLS handshake fails when we use TLS 1.2 in mbedtls 3.6.2 instead of 1.3. We get below error 20E094B0FFFF0000:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while reading:/usr/src/debug/openssl/3.1.0-r0/ssl/record/rec_layer_s3.c:303: # openssl s_client -connect 192.168.142.1:7001 -no_tls1_3 fails After seeing the trace we have enabled ciphers but still we see the issue. please advise, thanks. Thanks Kavitha

3 months, 3 weeks

1
0
0 0

psa crypto driver for imx-smw

by kavitha bk

Hi all, We are trying to write a psa crypto driver for imx-smw . They have exposed psa certified public apis https://github.com/nxp-imx/imx-smw/tree/release/version_4.x/public/psa Is there any documentation to replace existing psa implementation to custom psa crypto implementation in mbedtls..Please advise on the approach to follow to call the custom apis to implement based on https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-3.6/docs/psa-driver-exampl… Thanks Kavitha

4 months, 1 week

1
0
0 0

Mbed TLS 3.6.4 Released

by Minos Galanakis

Hi Mbed TLS users, We have released Mbed TLS versions 3.6.4. These releases of Mbed TLS address several security issues, provide bug fixes, and bring other minor changes. Full details are available in the release notes (https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.4). We recommend all users to consider whether they are impacted, and to upgrade appropriately.

4 months, 2 weeks

2
2
0 0

Credential validation BEFORE first TLS handshake: the present and future of mbedtls_pk_sign/verify()

by Almut Herzog

Hi, Prior to the first TLS handshake our application is required to perform input validation of the provided credentials (from file or smart card) for this peer. One of those checks is to verify that private and public key match. We used to use mbedtls_pk_sign() with a custom mbedtls_pk_context for that. But in version 3.X mbedtls_pk_info_t was made private so mbedtls_pk_setup() with a custom mbedtls_pk_info_t whose sign_func would call into our smart card wrapper is no longer possible. Is there still a way to provide custom callback functions for signing in 3.6.4 somehow? Or any other workaround for early check of a key pair? Looking at 4.0.0-beta, also pk.h is no longer public. Will it still be possible to perform early validation of this peer's credentials prior to a first TLS handshake? How? While I am at it, it would be good to implement something that is future-proof. What else I have looked at: * mbedtls_pk_setup_opaque() might be the way to go but I do not find an example of how to link a key id to a custom signature function. * mbedtls_pk_setup_rsa_alt() would be useful if our application was always using RSA. * Both functions are no longer public in 4.0 Related: Early validation of a CRL (whether it was signed by the expected CA) used to be possible with mbedtls_pk_verify_ext(). But to properly set the input parameters requires access to private members of mbedtls_x509_crl in 3.6.4 (maybe an acceptable move?) but in 4.0.0 mbedtls_pk_verify_ext() is no longer public. How perform explicit/"manual" CRL validation especially given the possibly skipped CRL validation in mbedtls_x509_crt_verify() as per the comment below? "It is your responsibility to provide up-to-date CRLs for all trusted CAs. If no CRL is provided for the CA that was used t sign the certificate, CRL verification is skipped silently..." Any future-proof ideas for this? Best regards, /Almut

4 months, 2 weeks

2
1
0 0

Re: MBed-TLS Technical Forum - Asia

by Gilles Peskine

Hello, Due to holidays, Arm will be unable to host a meeting on 14 July 2025. Slides are available at https://github.com/TrustedFirmwareWebsite/website/pull/652/files#diff-ee947… and will be on the archive web site shortly. Short summary of the past 2 weeks: the 3.6.4 release is out. We are now focusing on the last tasks for the 1.0/4.0 big release at end of Q3. Best regards, -- Gilles Peskine Mbed TLS developer and PSA Crypto architect ________________________________ From: Trusted Firmware Public Meetings Sent: 21 May 2025 14:56 To: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>; mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>; psa-crypto(a)lists.trustedfirmware.org <psa-crypto(a)lists.trustedfirmware.org> Subject: MBed-TLS Technical Forum - Asia When: 14 July 2025 11:00-11:50. Where: Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed-TLS Technical Forum - Asia Time: 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…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmeeting%2Ft…> Join Zoom Meeting https://linaro-org.zoom.us/j/97758661706?pwd=baMjUvnWbY20z3ignQca7QVahhozkI…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9775866…> Meeting ID: 977 5866 1706 Passcode: 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-free Meeting ID: 977 5866 1706 Find your local number: https://linaro-org.zoom.us/u/acdtApJNbc<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FacdtApJ…> When Every 4 weeks from 10am to 10:50am on Monday (United Kingdom Time) Guests mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org> View all guest info<https://calendar.google.com/calendar/event?action=VIEW&eid=NjI4c3NnYjFoZHRh…> RSVP for psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org> for all events in this series Yes<https://calendar.google.com/calendar/event?action=RESPOND&eid=NjI4c3NnYjFoZ…> No<https://calendar.google.com/calendar/event?action=RESPOND&eid=NjI4c3NnYjFoZ…> Maybe<https://calendar.google.com/calendar/event?action=RESPOND&eid=NjI4c3NnYjFoZ…> More options<https://calendar.google.com/calendar/event?action=VIEW&eid=NjI4c3NnYjFoZHRh…> 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>

5 months, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls