- mbed-tls - lists.trustedfirmware.org

extract AKI info from cert via mbedtls ?

by Danny Backx

Hi, How can I extract the AKI (Authority Key Identifier) from a certificate using mbedtls ? I could parse the certificate file itself, I guess, but isn't that what mbedtls does? Thanks, Danny https://www.rfc-editor.org/info/rfc5280#section-4.2.1.1 -- Danny Backx - dannybackx(a)telenet.be

1 day, 6 hours

3
4
0 0

Proposal to unify tf.org vulnerability referencing in NVD

by sandrine.afsa＠arm.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

2 weeks, 2 days

1
0
0 0

CI infrastructure scheduled maintenance: 4th June Sep 2026

by Saheer Babu

Hi all, We will be upgrading Cloudbees CI and clusters hosting review.trustedfirmware.org and ci.trustedfirmware.org on Wednesday, 3rd June 2025 at 16:00 GMT+1. During this maintenance window, both services will be unavailable for approximately 8 hours. A follow-up email will be sent once the services are fully restored. Best regards, Saheer [LOGO SMALL] Saheer Babu Principal Software Engineer CESW – Engineering Infrastructure

2 weeks, 3 days

1
2
0 0

need help migrating to mbedtls 4.0 (esp32)

by Danny Backx

I got into trouble with migrating to the latest (v6.0) version of esp-idf, because it implies a migration to mbedtls 4.0. I had a working application (library really) to obtain ACME certificates from letsencrypt.org. I tried porting, but ran into trouble. So please help. To debug, I try to mimic the example in Appendix A.2 of RFC 7515. Where this should obviously succeed, the current output I get is : I (12:57:46.067) main_task: Calling app_main() I (12:57:46.088) Crypto: Acme standalone client example © 2026 by Danny Backx I (12:57:46.089) Crypto: checkRfc7515_a21 Base64({"alg":"RS256"}) -> eyJhbGciOiJSUzI1NiJ9 is correct I (12:57:46.094) Crypto: checkRfc7515_a21 Base64({"iss":"joe", "exp":1300819380, "http://example.com/is_root":true}) -> eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ is correct I (12:57:46.121) Crypto: checkRfc7515_a21 importPrivateKey() -> 1073741825 E (12:57:46.122) psa_crypto: psa_get_and_lock_key_slot_with_policy psa_key_policy_permits -> -133 E (12:57:46.129) psa_crypto: psa_sign_internal psa_get_and_lock_key_slot_with_policy -> -133 E (12:57:46.137) Crypto: psa_sign_hash (key 1073741825) failed (not permitted, -133 0x0085) I (12:57:46.145) Crypto: checkRfc7515_a21 Signature(eyJhbGciOiJSUzI1NiJ9,eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ) -> (null) E (12:57:46.161) Crypto: Signature 0, fail E (12:57:46.165) Crypto: RFC 7515 A.2.1 : validation failed Some of the "psa_crypto" lines come from debug statements I added in the library. The whole source for this is in one file at https://sourceforge.net/p/esp32-acme-client/code/HEAD/tree/trunk/examples/s… . Obviously it's the hashing step which I had under control with a previous library which I don't call correctly (or I don't know how to import the right key). What am I doing wrong ? Thanks, Danny -- Danny Backx - dannybackx(a)telenet.be

1 month

2
2
0 0

mbedtls_ssl_read() return code MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET

by Fabian Keil

I'm currently working on adding MbedTLS 4.x support for Privoxy [0] and noticed that mbedtls_ssl_read() frequently returns MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET. Apparently the error code was added in f8a4994ec7 and marked experimental in da13072c5b. It doesn't seem explicitly documented at [1], but of course it's covered by "or another negative error code". My current solution is to simply continue reading: extern int ssl_recv_data(struct ssl_attr *ssl_attr, unsigned char *buf, size_t max_length) { [...] do { ret = mbedtls_ssl_read(ssl, buf, max_length); #if MBEDTLS_VERSION_MAJOR > 3 if (ret == MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET) { log_error(LOG_LEVEL_CONNECT, "mbedtls_ssl_read() reported new session ticket for " "the connection on socket %d.", ssl_attr->mbedtls_attr.socket_fd.fd); } #endif } while (ret == MBEDTLS_ERR_SSL_WANT_READ #if MBEDTLS_VERSION_MAJOR > 3 || ret == MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET #endif || ret == MBEDTLS_ERR_SSL_WANT_WRITE); When using MbedTLS 4.1.0 on ElectroBSD 14.4-STABLE this seems to work. For some connections the log message is emitted once, for others it's emitted twice: 09:20:58.982 024 Connect: Connected to 127.0.1.2[127.0.1.2]:9050. 09:20:59.222 024 Connect: Created new connection to www.electrobsd.org:443 on socket 9. 09:20:59.243 024 Connect: Performing the TLS handshake with the server. 09:20:59.583 024 Connect: Server successfully connected over TLSv1.3 (TLS1-3-CHACHA20-POLY1305-SHA256). 09:20:59.583 024 Connect: Encrypted request sent. 09:20:59.809 024 Connect: mbedtls_ssl_read() reported new session ticket for the connection on socket 9. 09:20:59.902 024 Connect: mbedtls_ssl_read() reported new session ticket for the connection on socket 9. 09:21:00.041 024 Header: scan: HTTP/1.1 200 OK I noticed that there's already an open ticket [2] which contains the sentence: | For client side, mbedtls_ssl_{read,write} might return the error also, | we should process it in the error handler also. I haven't seen mbedtls_ssl_write() return MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET yet, though. Can you confirm that handling MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET by continuing reading is currently the best option? Thanks. Fabian [0]: <https://www.privoxy.org/> [1]: <https://os.mbed.com/teams/sandbox/code/mbedtls/docs/tip/ssl_8h.html#aa2c29e…> [2]: <https://github.com/Mbed-TLS/mbedtls/issues/6640>

1 month, 3 weeks

2
2
0 0

Could anyone please handle this PR?

by Elsa zz

Hi, Could anyone please handle this PR? Fix build warning/error using llvm-mingw: - https://github.com/Mbed-TLS/mbedtls/pull/10695 Thanks!

2 months

1
0
0 0

Max. heap size for X509 certificate chain verification

by Huber, Ralf

Dear Mbed TLS contributors, I am working on an embedded project where we need to verify an X509 certificate chain with up to 4 certificates (root cert + 2 intermediates + client cert) and a CRL. The certificates contain public keys for ECDSA for the SECP_R1_256 curve. We are using mbedTLS 4.x. There is no heap memory in this project. It is a vehicle control ECU and all RAM is normally statically allocated for safety reasons. However, the certificate verification is not safety critical. It is OK for us to use mbedtls_memory_buffer_alloc_init() as a heap replacement for mbedTLS. I will refer to this as the "heap" for the rest of this mail. I would like to find out how large the heap needs to be for the chain verification. The system requirements state that it shall support certificates and CRL in DER format with a size of up to 2 kB each. There are 10 kB of static RAM buffer to store 4 certificates and the CRL. The certificates are parsed with mbedtls_x509_crt_parse_der_nocopy(), so the certificate raw data is not duplicated on the heap. The CRL is parsed with mbedtls_x509_crl_parse_der(), so I am expecting that the CRL raw data will be copied to the heap. Thus, it needs to be at least 2 kB. Unfortunately, there seems to be no "_nocopy()" function for CRLs. 8 kB heap was enough in my tests to verify a chain of 3 test certificates with sizes of ca. 0.5 kB each. 6 kB heap wasn't enough to do this. Is there a way to calculate or at least estimate the maximum required heap for the given maximum certificate and CRL sizes, such that a call of mbedtls_x509_crt_verify() for the chain will never fail due to insufficient memory? Is the required heap size fixed for a given number of certificates, or does it depend on the content of the certificates? If it does depend on the content, is there some way to construct "worst case certificates" that result in maximum heap usage, so I could use them to measure the heap consumption? Any help on this topic is kindly appreciated! Best regards, Ralf Huber KION Supply Chain Solutions Linde Material Handling GmbH, Sitz der Gesellschaft: Aschaffenburg, Registergericht: Aschaffenburg HRB9963, Ust-IdNr. DE814809128, Gesch?ftsf?hrung: Andreas Krinninger (Vorsitzender), Dr. Karoline Jung-Senssfelder, Ulrike Just, Dr. Frank Schepp, Vorsitzende des Aufsichtsrats: Valeria Gargiulo

2 months, 1 week

2
3
0 0

Migration from Mbed TLS 2.x to 3.6.x — key export

by Piotr Kurowski (Nokia)

Dear MbedTLS team, I maintain the Mbed TLS integration for our embedded products. We are still migrating from Mbed TLS 2.x to 3.6.x and need guidance on replacing the legacy SSL key export behavior. One of our legacy products utilizes handshake key material from mbedtls_ssl_conf_export_keys_cb in an accelerator. For compatibility with existing deployments, we must preserve this key export so the other side can decode. Section “SSL key export interface change” in 3.0-migration-guide.md (as referenced for the 3.6.x line) states that mbedtls_ssl_conf_export_keys_cb() and mbedtls_ssl_conf_export_keys_ext_cb() were replaced with mbedtls_ssl_set_export_keys_cb(), and that the new callback no longer exports raw keys and IV. The guide suggests that applications requiring raw traffic keys may derive them from the master secret and handshake transcript hashes from the on-wire data. I'm not sure how this can be coded. What is the recommended way to obtain or derive the raw keys and IV (or equivalent data) under the 3.6.x API? Could you point to documentation, examples of code would be very beneficial. We would also like to align with the 4.1.x in future. If there are changes in this area, we are interested in a common and supported approach to avoid repeated breaking migrations. Thank you for your time. Kind regards, Piotr

2 months, 3 weeks

1
0
0 0

Synced invitation: MBed TLS Technical Forum - US @ Mon 4 May 2026 4:30pm - 5:30pm (BST) (mbed-tls@lists.trustedfirmware.org)

by shaun.longhorn＠linaro.org

This email keeps the event up to date in your calendar. MBed TLS Technical Forum - US Monday 4 May 2026 ⋅ 4:30pm – 5:30pm United Kingdom Time Trusted Firmware is inviting you to a scheduled Zoom meeting.Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: MBed TLS Tech Forum - USTime: Aug 28, 2023 04:30 PM London Every 4 weeks on Mon, 20 occurrence(s) Aug 28, 2023 04:30 PM Sep 25, 2023 04:30 PM Oct 23, 2023 04:30 PM Nov 20, 2023 04:30 PM Dec 18, 2023 04:30 PM Jan 15, 2024 04:30 PM Feb 12, 2024 04:30 PM Mar 11, 2024 04:30 PM Apr 8, 2024 04:30 PM May 6, 2024 04:30 PM Jun 3, 2024 04:30 PM Jul 1, 2024 04:30 PM Jul 29, 2024 04:30 PM Aug 26, 2024 04:30 PM Sep 23, 2024 04:30 PM Oct 21, 2024 04:30 PM Nov 18, 2024 04:30 PM Dec 16, 2024 04:30 PM Jan 13, 2025 04:30 PM Feb 10, 2025 04:30 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJ0udu2spj0vHtbQtlCmHwhHCT7ECtJI39J4/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/99314486542?pwd=Q1ZjaFhQeDRrQWxsa3MvT1Mwditqdz09Meeting ID: 993 1448 6542Passcode: 628327---One tap mobile+13462487799,,99314486542# US (Houston)+16694449171,,99314486542# US---Dial by your location• +1 346 248 7799 US (Houston)• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +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 689 278 1000 US• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• 877 853 5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 993 1448 6542Find your local number: https://linaro-org.zoom.us/u/adSjuOyMhI Guests psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org ~~//~~ 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

2 months, 3 weeks

1
0
0 0

Synced invitation: MBed TLS Technical Forum - US @ Mon 6 Apr 2026 4:30pm - 5:30pm (BST) (mbed-tls@lists.trustedfirmware.org)

by shaun.longhorn＠linaro.org

This email keeps the event up to date in your calendar. MBed TLS Technical Forum - US Monday 6 Apr 2026 ⋅ 4:30pm – 5:30pm United Kingdom Time Trusted Firmware is inviting you to a scheduled Zoom meeting.Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: MBed TLS Tech Forum - USTime: Aug 28, 2023 04:30 PM London Every 4 weeks on Mon, 20 occurrence(s) Aug 28, 2023 04:30 PM Sep 25, 2023 04:30 PM Oct 23, 2023 04:30 PM Nov 20, 2023 04:30 PM Dec 18, 2023 04:30 PM Jan 15, 2024 04:30 PM Feb 12, 2024 04:30 PM Mar 11, 2024 04:30 PM Apr 8, 2024 04:30 PM May 6, 2024 04:30 PM Jun 3, 2024 04:30 PM Jul 1, 2024 04:30 PM Jul 29, 2024 04:30 PM Aug 26, 2024 04:30 PM Sep 23, 2024 04:30 PM Oct 21, 2024 04:30 PM Nov 18, 2024 04:30 PM Dec 16, 2024 04:30 PM Jan 13, 2025 04:30 PM Feb 10, 2025 04:30 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJ0udu2spj0vHtbQtlCmHwhHCT7ECtJI39J4/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/99314486542?pwd=Q1ZjaFhQeDRrQWxsa3MvT1Mwditqdz09Meeting ID: 993 1448 6542Passcode: 628327---One tap mobile+13462487799,,99314486542# US (Houston)+16694449171,,99314486542# US---Dial by your location• +1 346 248 7799 US (Houston)• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +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 689 278 1000 US• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• 877 853 5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 993 1448 6542Find your local number: https://linaro-org.zoom.us/u/adSjuOyMhI Guests psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org ~~//~~ 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

2 months, 3 weeks

1
0
0 0

Updated invitation with note: MBed TLS Technical Forum - US @ Every 4 weeks from 4:30pm to 5:30pm on Monday (BST) (mbed-tls@lists.trustedfirmware.org)

by Shaun Longhorn

This event has been updated with a note: "Updated expired zoom link" Changed: title, time, description MBed TLS Technical Forum - US Every 4 weeks from 4:30pm to 5:30pm on Monday United Kingdom Time Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: MBed TLS Technical Forum - USTime: May 4, 2026 04:30 PM LondonEvery 4 weeks on Mon, 38 occurrence(s)Please download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJcoc--qrz0uHNNmuZMtfpylBgIZjC2so7xz/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/93546216467?pwd=ja9Nxd0uLBn04jg1Be0NTy17Konzfl.1Meeting ID: 935 4621 6467Passcode: 683772---One tap mobile+13126266799,,93546216467# US (Chicago)+13462487799,,93546216467# US (Houston)---Dial by your location• +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)• +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• 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• 833 548 0282 US Toll-free• 833 928 4608 US Toll-freeMeeting ID: 935 4621 6467Find your local number:https://linaro-org.zoom.us/u/azKzC20VI Guests psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=dm9wcGhnbnZvMnRh… Reply for mbed-tls(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=dm9wcGhnbnZvMnRh… 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

2 months, 3 weeks

1
0
0 0

Updated invitation: MBed TLS Technical Forum @ Every 4 weeks from 4:30pm to 5:30pm on Monday from Mon 13 Mar 2023 to Sun 31 May (GMT) (mbed-tls@lists.trustedfirmware.org)

by Shaun Longhorn

This event has been updated Changed: time MBed TLS Technical Forum Every 4 weeks from 4:30pm to 5:30pm on Monday from Monday 13 Mar 2023 to Sunday 31 May United Kingdom Time Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum Time: Oct 25, 2021 04:30 PM London Every 4 weeks on Mon, 20 occurrence(s) Oct 25, 2021 04:30 PM Nov 22, 2021 04:30 PM Dec 20, 2021 04:30 PM Jan 17, 2022 04:30 PM Feb 14, 2022 04:30 PM Mar 14, 2022 04:30 PM Apr 11, 2022 04:30 PM May 9, 2022 04:30 PM Jun 6, 2022 04:30 PM Jul 4, 2022 04:30 PM Aug 1, 2022 04:30 PM Aug 29, 2022 04:30 PM Sep 26, 2022 04:30 PM Oct 24, 2022 04:30 PM Nov 21, 2022 04:30 PM Dec 19, 2022 04:30 PM Jan 16, 2023 04:30 PM Feb 13, 2023 04:30 PM Mar 13, 2023 04:30 PM Apr 10, 2023 04:30 PM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJEkceuurT4sGdaksikbUn6FARB9Kuk3ac2o/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/95962635632?pwd=STFkQVltejAzRDJ6NmoxZjhmZC9RUT… Meeting ID: 959 6263 5632 Passcode: 018366 One tap mobile +13462487799,,95962635632# US (Houston) +16699009128,,95962635632# US (San Jose) Dial by your location +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) +1 301 715 8592 US (Washington DC) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 959 6263 5632 Find your local number: https://linaro-org.zoom.us/u/aewUpnQu5y Guests psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=ZGExMnNqcDB1MDFm… Reply for mbed-tls(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=ZGExMnNqcDB1MDFm… 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

2 months, 3 weeks

1
0
0 0

Synced invitation: MBed TLS Technical Forum - US @ Every 4 weeks from 4:30pm to 5:30pm on Monday from Mon 28 Aug 2023 to Sun 31 May (BST) (mbed-tls@lists.trustedfirmware.org)

by Shaun Longhorn

This email keeps the event up to date in your calendar. MBed TLS Technical Forum - US Every 4 weeks from 4:30pm to 5:30pm on Monday from Monday 28 Aug 2023 to Sunday 31 May United Kingdom Time Trusted Firmware is inviting you to a scheduled Zoom meeting.Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: MBed TLS Tech Forum - USTime: Aug 28, 2023 04:30 PM London Every 4 weeks on Mon, 20 occurrence(s) Aug 28, 2023 04:30 PM Sep 25, 2023 04:30 PM Oct 23, 2023 04:30 PM Nov 20, 2023 04:30 PM Dec 18, 2023 04:30 PM Jan 15, 2024 04:30 PM Feb 12, 2024 04:30 PM Mar 11, 2024 04:30 PM Apr 8, 2024 04:30 PM May 6, 2024 04:30 PM Jun 3, 2024 04:30 PM Jul 1, 2024 04:30 PM Jul 29, 2024 04:30 PM Aug 26, 2024 04:30 PM Sep 23, 2024 04:30 PM Oct 21, 2024 04:30 PM Nov 18, 2024 04:30 PM Dec 16, 2024 04:30 PM Jan 13, 2025 04:30 PM Feb 10, 2025 04:30 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJ0udu2spj0vHtbQtlCmHwhHCT7ECtJI39J4/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/99314486542?pwd=Q1ZjaFhQeDRrQWxsa3MvT1Mwditqdz09Meeting ID: 993 1448 6542Passcode: 628327---One tap mobile+13462487799,,99314486542# US (Houston)+16694449171,,99314486542# US---Dial by your location• +1 346 248 7799 US (Houston)• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +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 689 278 1000 US• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• 877 853 5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 993 1448 6542Find your local number: https://linaro-org.zoom.us/u/adSjuOyMhI Guests psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org ~~//~~ 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

2 months, 3 weeks

1
0
0 0

Canceled event with note: MBed TLS Technical Forum - US @ Mon 6 Apr 2026 4:30pm - 5:30pm (BST) (mbed-tls@lists.trustedfirmware.org)

by Shaun Longhorn

This event has been canceled with a note: "cancelled due to holidays" MBed TLS Technical Forum - US Monday 6 Apr 2026 ⋅ 4:30pm – 5:30pm United Kingdom Time Trusted Firmware is inviting you to a scheduled Zoom meeting.Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: MBed TLS Tech Forum - USTime: Aug 28, 2023 04:30 PM London Every 4 weeks on Mon, 20 occurrence(s) Aug 28, 2023 04:30 PM Sep 25, 2023 04:30 PM Oct 23, 2023 04:30 PM Nov 20, 2023 04:30 PM Dec 18, 2023 04:30 PM Jan 15, 2024 04:30 PM Feb 12, 2024 04:30 PM Mar 11, 2024 04:30 PM Apr 8, 2024 04:30 PM May 6, 2024 04:30 PM Jun 3, 2024 04:30 PM Jul 1, 2024 04:30 PM Jul 29, 2024 04:30 PM Aug 26, 2024 04:30 PM Sep 23, 2024 04:30 PM Oct 21, 2024 04:30 PM Nov 18, 2024 04:30 PM Dec 16, 2024 04:30 PM Jan 13, 2025 04:30 PM Feb 10, 2025 04:30 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJ0udu2spj0vHtbQtlCmHwhHCT7ECtJI39J4/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/99314486542?pwd=Q1ZjaFhQeDRrQWxsa3MvT1Mwditqdz09Meeting ID: 993 1448 6542Passcode: 628327---One tap mobile+13462487799,,99314486542# US (Houston)+16694449171,,99314486542# US---Dial by your location• +1 346 248 7799 US (Houston)• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +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 689 278 1000 US• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• 877 853 5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 993 1448 6542Find your local number: https://linaro-org.zoom.us/u/adSjuOyMhI Guests psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org ~~//~~ 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

2 months, 3 weeks

1
0
0 0

Announcing the releases of Mbed TLS 3.6.6, Mbed TLS 4.1.0 & TF-PSA-Crypto 1.1.0

by Minos Galanakis

Hi Mbed TLS users, We have released Mbed TLS 4.1.0, Mbed TLS 3.6.6, and TF-PSA-Crypto 1.1.0. These releases address several security issues, include bug fixes, and bring other improvements. Mbed TLS 4.1.0 and TF-PSA-Crypto 1.1.0 are new Long Term Support (LTS) releases and will be supported until March 2029. Mbed TLS 3.6 remains supported until March 2027. We recommend all users review the changes, assess any impact, and upgrade as appropriate. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.1.0 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.6 https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.1.0 Kind regards, The Mbed TLS Team

2 months, 3 weeks

1
0
0 0

[Mbed-tls-announce] Announcing the releases of Mbed TLS 3.6.6, Mbed TLS 4.1.0 & TF-PSA-Crypto 1.1.0

by Minos Galanakis via Mbed-tls-announce

Hi Mbed TLS users, We have released Mbed TLS 4.1.0, Mbed TLS 3.6.6, and TF-PSA-Crypto 1.1.0. These releases address several security issues, include bug fixes, and bring other improvements. Mbed TLS 4.1.0 and TF-PSA-Crypto 1.1.0 are new Long Term Support (LTS) releases and will be supported until March 2029. Mbed TLS 3.6 remains supported until March 2027. We recommend all users review the changes, assess any impact, and upgrade as appropriate. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.1.0 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.6 https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.1.0 Kind regards, The Mbed TLS 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

2 months, 3 weeks

1
0
0 0

Canceled event with note: MBed TLS Technical Forum - US @ Mon 4 May 2026 4:30pm - 5:30pm (BST) (mbed-tls@lists.trustedfirmware.org)

by Shaun Longhorn

This event has been canceled with a note: "Cancelled due to holidays" MBed TLS Technical Forum - US Monday 4 May 2026 ⋅ 4:30pm – 5:30pm United Kingdom Time Trusted Firmware is inviting you to a scheduled Zoom meeting.Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: MBed TLS Tech Forum - USTime: Aug 28, 2023 04:30 PM London Every 4 weeks on Mon, 20 occurrence(s) Aug 28, 2023 04:30 PM Sep 25, 2023 04:30 PM Oct 23, 2023 04:30 PM Nov 20, 2023 04:30 PM Dec 18, 2023 04:30 PM Jan 15, 2024 04:30 PM Feb 12, 2024 04:30 PM Mar 11, 2024 04:30 PM Apr 8, 2024 04:30 PM May 6, 2024 04:30 PM Jun 3, 2024 04:30 PM Jul 1, 2024 04:30 PM Jul 29, 2024 04:30 PM Aug 26, 2024 04:30 PM Sep 23, 2024 04:30 PM Oct 21, 2024 04:30 PM Nov 18, 2024 04:30 PM Dec 16, 2024 04:30 PM Jan 13, 2025 04:30 PM Feb 10, 2025 04:30 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJ0udu2spj0vHtbQtlCmHwhHCT7ECtJI39J4/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/99314486542?pwd=Q1ZjaFhQeDRrQWxsa3MvT1Mwditqdz09Meeting ID: 993 1448 6542Passcode: 628327---One tap mobile+13462487799,,99314486542# US (Houston)+16694449171,,99314486542# US---Dial by your location• +1 346 248 7799 US (Houston)• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +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 689 278 1000 US• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• 877 853 5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 993 1448 6542Find your local number: https://linaro-org.zoom.us/u/adSjuOyMhI Guests psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org ~~//~~ 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

2 months, 3 weeks

1
0
0 0

Notice of refactoring of C11 and Unix-like platform adherence

by Gilles Peskine

Hello, In the next release of TF-PSA-Crypto 1.1.0 and Mbed TLS 4.1.0, we have made significant changes to code that detects features that are not part of C99 proper. The changes are mainly: * Uniformization of POSIX/Unix feature detection macros. * Assume a C99-compliant printf (dropping hacks for ancient MSVC and forcing compliant printf on MinGW). * Expansion of “static assert” in C99 when an official C11 static_assert isn't available. We believe the new code to be standards-compliant, however it may break the build on some platforms that are not strictly POSIX compliant or cause some new compiler warnings. If you use TF-PSA-Crypto or Mbed TLS on a “less mainstream” Unix-like platform, or with a compiler that isn't GCC or Clang, and the break builds for you, please open a pull request with the necessary fixes (probably in core/tf_psa_crypto_platform_requirements.h, core/tf_psa_crypto_common.h, or library/mbedtls_platform_requirements.h). We have also made some minor changes in the Mbed TLS 3.6 long-time support branch. They are significantly less expansive, but may affect platforms that are mostly Linux-like but are not Linux or are using an unusual libc. Best regards, -- Gilles Peskine TF-PSA-Crypto and Mbed TLS developer

3 months, 1 week

1
0
0 0

ECDH and key interfaces on development branch

by Leonie Reichert

Dear MbedTLS contributors, I'm reaching out with a question regarding the ECDH and similar interfaces on the MbedTLS development branch. I hope this mailing list is the appropriate venue for this discussion. I am preparing a pull request for an implementation of the Hybrid Public Key Encryption (HPKE) standard for MbedTLS/TF-PSA-Crypo. It seems like the development branch at TF-PSA-Crypo does not seem to support ecdh.h anymore. While this is not seem to be explicitly stated anywhere, there are instructions on how to use the PSA interface instead to create ECDH keys. Now my question: So the my code meets the desired quality criteria, does all other key interfaces also have to be changed? I am using the ECP interface a lot, so mbedtls_ecp_group_init, mbedtls_ecp_point_init, mbedtls_ecp_keypair_init and so on. The functions are still available but the instructions in psa_tranistion.md in Section "translating a legacy ephemeral key agreement TLS server workflow" make me believe that using non-psa key interfaces might be undesirable in MbedTLS in general. I would greatly appreciate any clarification on this matter. Best regards, Leonie [ABB logotype] — Dr. Leonie Reichert Research Scientist "Secure Connected Systems" ABB AG Kallstadter Strasse 1 Mannheim Mobile: +49 160 99002896 E-mail: leonie.reichert(a)de.abb.com<mailto:leonie.reichert@de.abb.com> abb.com<https://www.abb.com/> [ABB logotype] ABB AG Sitz/Head Office: Mannheim Registergericht/Registry Court: Mannheim Handelsregisternummer/Commercial Register No.: HRB 4664 Vorstand/Managing Board: Klaus Eble (Vorsitzender/Chairman), Alexander Zumkeller Vorsitzender des Aufsichtsrats/ Chairman of Supervisory Board: Adrian Guggisberg Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Bitte beachten Sie auch unsere Datenschutzerklärung, die Sie auf unserer Webseite<https://new.abb.com/privacy-policy/de/datenschutz> finden. This E-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this E-mail in error) please notify the sender immediately and destroy this E-mail. Any unauthorized copying, disclosure or distribution of the material in this E-mail is strictly forbidden. Please also take note of our privacy notice, which you can find on our webpage<https://new.abb.com/privacy-notice>.

3 months, 2 weeks

2
2
0 0

[TLS 1.2][ECDHE][RX65N] point is not on curve (secp256r1)

by Adrien LEGER

Hello, I am using mbedTLS 3.6.5 on a Renesas RX65N with compiler ccrx. I am implementing a TLS 1.2 server using: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - ECDSA P-256 server certificate - ECDHE secp256r1 During the handshake (I use openssl s_client), I get: >>> TLS 1.2, Alert [length 0002], fatal illegal_parameter 02 2f 140605661713728:error:1012606B:elliptic curve routines:EC_POINT_set_affine_coordinates:point is not on curve:../crypto/ec/ec_lib.c:812: 140605661713728:error:141A4132:SSL routines:tls_process_ske_ecdhe:bad ecpoint:../ssl/statem/statem_clnt.c:2229: mbedtls_ecdh_make_params() returned -0x4C80 (MBEDTLS_ERR_ECP_INVALID_KEY) This happens right after: ssl_tls12_server.c:4304: server state: 4 ssl_tls12_server.c:3234: => write server key exchange ssl_tls12_server.c:2971: ECDHE curve: secp256r1 ssl_tls12_server.c:3075: value of 'ECDH: Q(X)' (256 bits) is: ssl_tls12_server.c:3075: f0 7e c6 f3 cc 41 71 bb a8 01 0b cc 3a 8a 5e 72 ssl_tls12_server.c:3075: 9d db bc d9 a1 5a 04 91 47 44 e0 ff 6f 42 de b3 ssl_tls12_server.c:3075: value of 'ECDH: Q(Y)' (255 bits) is: ssl_tls12_server.c:3075: 5e ba af af 86 55 1a 6e 04 a8 97 b4 13 12 c2 3c ssl_tls12_server.c:3075: a3 2e 00 a4 2d 44 e8 63 bf 98 08 74 81 94 5f 5e ssl_tls12_server.c:3130: pick hash algorithm 9 for signing ssl_tls.c:9231: Perform mbedtls-based computation of digest of ServerKeyExchange ssl_tls12_server.c:3148: dumping 'parameters hash' (32 bytes) ssl_tls12_server.c:3148: 0000: 2d b3 aa 62 c4 5a 87 18 39 a6 b6 91 0e 6d fb 81 -..b.Z..9....m.. ssl_tls12_server.c:3148: 0010: f7 55 38 54 33 1d 30 cc 85 83 10 2e 39 5c 5d 67 .U8T3.0.....9\]g ssl_tls12_server.c:3296: dumping 'my signature' (72 bytes) ssl_tls12_server.c:3296: 0000: 30 46 02 21 00 ee 81 dd 1f 32 62 66 57 5c 90 31 0F.!.....2bfW\.1 ssl_tls12_server.c:3296: 0010: a9 84 2a c4 e8 ee 6a c5 f0 db 39 01 58 d5 9c e3 ..*...j...9.X... ssl_tls12_server.c:3296: 0020: 6e e6 bd 04 25 02 21 00 f5 c6 89 97 d8 dd 2f 93 n...%.!......./. ssl_tls12_server.c:3296: 0030: d0 11 19 f7 0a e7 c4 6b ae 27 b8 d5 db b4 a9 2c .......k.'....., ssl_tls12_server.c:3296: 0040: 2f ec 2e b4 53 1a 72 01 I suspect an entropy / RNG issue. My RNG initialization is: - custom entropy source based on XXX - added via mbedtls_entropy_add_source(...) - CTR_DRBG seeded with personalization string "debug-seed" Do you see any problem in this setup ? Do not hesitate if you need any other information. I'm new to cryptography and currently learning TLS with mbedTLS. Thanks in advance, Adrien.

3 months, 4 weeks

2
1
0 0

Performance Inquiry- High read/write latency observed in Mbedtls 3.6.2 (DTLS)

by Ankita Hatmode

Hi Team, We are working on an embedded security project using MbedTLS 3.6.2 for DTLS communication. As part of our performance evaluation, we analyzed the timing metrics for DTLS handshake and application data read/write operations. During testing, we observed that the time taken for data read and write operations is significantly higher than expected. [image: image.png] We would appreciate your guidance on the following: 1. What factors in MbedTLS could contribute to higher read/write latency? 2. Are there any known performance limitations or configuration settings that impact DTLS data transfer timing? 3. Are there recommended optimizations for embedded platforms to improve throughput? Please let us know if any more info is required. 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. ------------------------------------------------------------------------------------------------------------------------

4 months

2
1
0 0

mbedtls 2.28 - resumption in an ongoing session (abbreviated renegotiation)

by Tommaso Mancini

Hello, I am trying to test a device’s conformance to IEC62351-3 which defines some rules about TLS implementations, in particular im wondering if it’s possible to: Use mbedtls on a TLS server to accept a session resumption when a client sends a ClientHello message with a session ID in an ongoing TLS session. Also RFC 5246 says this about resumption for tls v1.2: The ClientHello message includes a variable-length session identifier. If not empty, the value identifies a session between the same client and server whose security parameters the client wishes to reuse. The session identifier MAY be from an earlier connection, this connection, or from another currently active connection. so it should be possible to resume in an ongoing session but: I already have a working implementation of a TLS 1.2 server using mbedtls 2.28, but if a client sends a clienthello with a session ID in an ongoing session, the server always responds with a renegotiation by default. Taking a look at the library code i tried to change the function: static void ssl_handle_id_based_session_resumption(mbedtls_ssl_context *ssl) found in the file ssl_srv.c in mbedtls 2.28, and removed a check which skipped resumption if a client hello was received during a session, this does not work properly however because the server closes the connection after sending the finished message due to a MBEDTLS_SSL_ALERT_MSG_DECRYPT_ERROR. Im wondering if there is anyway to allow resumption in this manner using mbedtls or if im doing something wrong? If you require further information please let me know and i will try to add as much as i can! [1741361442716] <mailto:tommaso.mancini@sel-electric.it> Tommaso Mancini SEL S.p.A. R&D Software and Test Engineer Via Amendola 9,11,13,15,17 51035 Lamporecchio (PT) Tel. +39 0573 80051 Fax +39 0573 803110 website: www.sel-electric.com<http://www.sel-electric.com/> e-mail: tommaso.mancini(a)sel-electric.it<mailto:tommaso.mancini@sel-electric.it> <mailto:tommaso.mancini@sel-electric.it>Questo è un messaggio di posta elettronica proveniente da SEL s.p.a. Le informazioni contenut in questa comunicazione sono altamente riservate e possono essere utilizzate solo dalla persona o dall’ente cui sono destinate. La diffusione, distribuzione e/o copiatura del documento trasmesso da parte di qualsiasi soggetto diverso dal destinatario è proibita. Se avete ricevuto questo messaggio per errore, Vi preghiamo di contattarci immediatamente. Grazie. This communication is intended only for use by the addressee. It may contain confidential or privileged information. Transmission cannot be guaranteed to be secure or error-free. If you receive this communication unintentionally, please inform us immediately. Thank you. Per favore, pensa all’ambiente prima di stampare. Please, consider the environment before you print.

4 months, 3 weeks

1
0
0 0

Some problems regarding mbed TLS

by Milorad Podoaba

Hello, Our devices are connecting to AWS IoT Core. Recently we had few customers with poor connection complaining that the device didn't reconnect. We are using ARM Keil MDK 8.1.0 + mbed TLS 3.6.4. On Wireshark logs we have identified 2 errors: 1. close notify from server after client hello 2. bad certificate or unknown CA from client after server hello The device was stuck on one of these errors and only a reboot would fix it. I think these 2 errors are not related. On detail analysis for the first error, we saw that the cipher suites list was missing and that was the reason for close notify from server. Looking at the TLS code saw that the list is being created only one time after reboot. So in ssl_ciphersuites.c just commented out supported_init = 1 and now seems to be good. I do not know the reason why the list was lost during runtime. For the second error, we were able to reproduce the problem quite consistently. Some logs at IoT client code showed that somehow the TLS lost the ability to parse properly the server certificates. I believe that this was some memory allocation problem, so I've configured the mbed TLS to get allocation from a separate buffer and that seems to fix the problem. This buffer has to be quite large, 56k size. Any smaller size would return memory allocation failure. Any reason why it has to be so big? Just want to know if someone had before these issues and if I can lower the buffer. Let me know if you need extra details about the problems. Thank you and regards, Milo -- MiloradPodoaba Firmware System Engineer Arrowhead Alarm Products Ltd. (09) 414 0085 <tel:%2809%29%20414%200085%20%20%20> milo(a)aap.co.nz <mailto:milo@aap.co.nz> www.aap.co.nz <//www.aap.co.nz> 1A Emirali Road, Silverdale, Auckland, New Zealand facebook <https://www.facebook.com/ArrowheadAlarmProductsLtd/?hc_ref=ARTrnwMZmLZimX6K…> linkedin <https://www.linkedin.com/company/arrowhead-alarm-products-ltd-/> instagram <https://instagram.com/aapltd?igshid=1356ehzmruf5r>

4 months, 3 weeks

3
3
0 0

Fwd: Some problems regarding mbed TLS

by Ben Taylor

Also anything you can share around the size and quantity of certificates you are parsing would be useful. 56K does seem very high, though if at the time you are parsing large numbers of large certificates it could get up that far. Regards Ben ---------- Forwarded message --------- From: Ben Taylor <ben.taylor(a)linaro.org> Date: Tue, 27 Jan 2026 at 11:33 Subject: Re: [mbed-tls] Some problems regarding mbed TLS To: Milorad Podoaba <milo(a)aap.co.nz> Hi Milo, For the second issue the memory allocation problem if you are able to share your mbedtls configuration, that would be useful as customising this could impact how much is allocated. Beyond this anything further you can share about how you are using the library when you encounter high usage would be useful. Ideally a code snippet which reproduces the error, though if not any further information will help us reproduce the error and attempt to assist you. For the first issue again if you can share your config and any code snippets you have that can reproduce the issue that would be helpful. Many thanks Ben On Mon, 26 Jan 2026 at 20:54, Milorad Podoaba <milo(a)aap.co.nz> wrote: > Hi Ben, > > Not sure how much code you want me to share. You need to be more specific. > There might be a memory problem in our application, it just hard to tell > and the mbed TLS seems not able to recover. > > At this stage, I only want to reduce the size of the buffer for the > alternative memory alloc. > Do you know a way to do it? > > Thank you and regards, > Milo > > > Milorad Podoaba > > Firmware System Engineer > > Arrowhead Alarm Products Ltd. > > > > (09) 414 0085 <%2809%29%20414%200085%20%20%20> > milo(a)aap.co.nz > www.aap.co.nz <//www.aap.co.nz> > 1A Emirali Road, Silverdale, Auckland, New Zealand > > > > [image: facebook] > <https://www.facebook.com/ArrowheadAlarmProductsLtd/?hc_ref=ARTrnwMZmLZimX6K…> > > [image: linkedin] > <https://www.linkedin.com/company/arrowhead-alarm-products-ltd-/> > > [image: instagram] <https://instagram.com/aapltd?igshid=1356ehzmruf5r> > > > On 27/01/2026 12:19 am, Ben Taylor wrote: > > Hi Milo, > Thanks for reporting this issue. Is there any chance you could > share some example code that can reproduce the error, so we can investigate > it further? > > Many thanks > > Ben > > On Mon, 26 Jan 2026 at 10:28, Milorad Podoaba via mbed-tls < > mbed-tls(a)lists.trustedfirmware.org> wrote: > >> Hello, >> >> Our devices are connecting to AWS IoT Core. >> Recently we had few customers with poor connection complaining that the >> device didn't reconnect. >> >> We are using ARM Keil MDK 8.1.0 + mbed TLS 3.6.4. >> >> On Wireshark logs we have identified 2 errors: >> >> 1. close notify from server after client hello >> 2. bad certificate or unknown CA from client after server hello >> >> The device was stuck on one of these errors and only a reboot would fix >> it. >> I think these 2 errors are not related. >> >> On detail analysis for the first error, we saw that the cipher suites >> list was missing and that was the reason for close notify from server. >> Looking at the TLS code saw that the list is being created only one time >> after reboot. >> So in ssl_ciphersuites.c just commented out supported_init = 1 and now >> seems to be good. >> I do not know the reason why the list was lost during runtime. >> >> For the second error, we were able to reproduce the problem quite >> consistently. >> Some logs at IoT client code showed that somehow the TLS lost the ability >> to parse properly the server certificates. >> I believe that this was some memory allocation problem, so I've >> configured the mbed TLS to get allocation from a separate buffer and that >> seems to fix the problem. >> This buffer has to be quite large, 56k size. Any smaller size would >> return memory allocation failure. >> Any reason why it has to be so big? >> >> Just want to know if someone had before these issues and if I can lower >> the buffer. >> Let me know if you need extra details about the problems. >> >> Thank you and regards, >> Milo >> >> >> -- >> Milorad Podoaba >> >> Firmware System Engineer >> >> Arrowhead Alarm Products Ltd. >> >> >> >> (09) 414 0085 <%2809%29%20414%200085%20%20%20> >> milo(a)aap.co.nz >> www.aap.co.nz <//www.aap.co.nz> >> 1A Emirali Road, Silverdale, Auckland, New Zealand >> >> >> >> [image: facebook] >> <https://www.facebook.com/ArrowheadAlarmProductsLtd/?hc_ref=ARTrnwMZmLZimX6K…> >> [image: linkedin] >> <https://www.linkedin.com/company/arrowhead-alarm-products-ltd-/> >> [image: instagram] <https://instagram.com/aapltd?igshid=1356ehzmruf5r> >> -- >> mbed-tls mailing list -- mbed-tls(a)lists.trustedfirmware.org >> To unsubscribe send an email to mbed-tls-leave(a)lists.trustedfirmware.org >> > >

4 months, 3 weeks

2
1
0 0

PSA Key derivation driver entry points

by Ruchika Gupta

Hi All, The PSA driver interface guide describes the driver entry points for key derivation. However the implementation seems to be missing from the psa crypto core layer. Can you help update if this is something which is being worked on ? I see a lot of tickets open related for key derivation interface dating back in 2022. Are these still relevant ? Regards, Ruchika

5 months, 1 week

2
1
0 0

2026

2025

2024

2023

2022

2021

2020