- mbed-tls - lists.trustedfirmware.org

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

7 hours, 45 minutes

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

1 day, 3 hours

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

1 day, 3 hours

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

1 day, 3 hours

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

1 day, 3 hours

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

1 day, 3 hours

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

1 day, 3 hours

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

1 day, 3 hours

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

1 day, 3 hours

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

1 day, 3 hours

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 weeks

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

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

1 month, 1 week

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

1 month, 1 week

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.

2 months

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>

2 months

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

2 months

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

2 months, 2 weeks

2
1
0 0

Canceled event: MBed-TLS Technical Forum - Asia @ Mon 29 Dec 2025 10am - 10:50am (GMT) (mbed-tls@lists.trustedfirmware.org)

by Shaun Longhorn

This event has been canceled. MBed-TLS Technical Forum - Asia Monday 29 Dec 2025 ⋅ 10am – 10:50am 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 ~~//~~ 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

3 months, 2 weeks

1
0
0 0

Question about using hardware-backed parameters in ALT crypto implementations

by Massimiliano Cialdi

Hi, I’m working with Mbed TLS 2.28.x on a microcontroller that provides a built-in crypto engine. The existing *_ALT support works fine for performance, and higher-level modules correctly route their block operations through the accelerated backend. On this platform the crypto hardware can also use internal key material stored in dedicated slots. These values are not accessible as byte arrays and cannot be passed to the usual setkey_*() API. Question Is there a recommended way to configure an ALT implementation so that it can select an internal key slot instead of receiving a buffer? Or, more generally, how should an ALT backend represent a key that is not exposed to software? Any guidance on the intended design would be appreciated. Thanks! Massimiliano Cialdi FIRMWARE ENGINEERING PROFESSIONAL LEADER Powersoft S.p.A. Via E. Conti, 5 - Scandicci (Fi) 50018 - Italy OFFICE: +39 055 7350230 [cid:2_3b23bc2c-3db3-4330-b6f5-3fb62b89422a.png]<https://www.facebook.com/powersoft/>[cid:3_7da2eb67-7c7f-41e6-9598-128bdd52ec04.png]<https://www.instagram.com/powersoft.official/>[cid:4_a5d469e7-3228-4fb1-948d-4c3e879ea0da.png]<https://www.youtube.com/@powersoftaudio>[cid:5_e4390674-51fd-4219-9389-28ae9a12796d.png]<https://www.linkedin.com/company/powersoft>[cid:6_083a55f9-076c-4d52-9f93-69225b28cb32.png]<https://open.spotify.com/show/6lwXROYcCyrVnJi6J9fA42>[cid:7_7fd8585e-63fd-441a-95f3-6c0b23d059e1.png]<https://x.com/Powersoft_Japan>[cid:8_6308aaa9-b97d-405b-a86c-0300a381d13f.png]<https://space.bilibili.com/3546387314641333>[cid:9_9af1e42f-0019-42c4-8046-d6246e65ed9e.png]<https://teams.microsoft.com/l/chat/0/0?users=massimiliano.cialdi@powersoft.…> [cid:pwsrgbn_12214209-f50f-45fa-be18-2a4cf1a5818a.png]<https://www.powersoft.com/en>

4 months, 1 week

2
1
0 0

Re: How can I read plain-text private key into rsa_context?

by Shannek Pierce

05 DC AD 24 F4 E4 B1 C4 39 15 62 45 02 DC 7B 4A C6 57 8F FC 40 5B 5E 6F 55 FB E1 F6 58 62 CB 57 05 Sent from my iPhone

4 months, 2 weeks

1
0
0 0

AI Policy - Guidance on AI-assisted contributions

by Shaun Longhorn

All, Please be aware that today we have published our AI policy with Guidance on AI-assisted contributions. See the full details here: https://www.trustedfirmware.org/aipolicy/ Should you have any questions feel free to raise them. Thanks, Shaun Community Manager

4 months, 2 weeks

1
0
0 0

Re: [Hafnium] Re: Gerrit scheduled maintenance: 8th November 8-12 UTC

by Saheer Babu

Hi Jerome Could you try again please? Thanks, Saheer From: Jerome Forissier <jerome.forissier(a)linaro.org> Date: Monday, 10 November 2025 at 10:19 To: Saheer Babu <Saheer.Babu(a)arm.com>, tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>, tf-rmm(a)lists.trustedfirmware.org <tf-rmm(a)lists.trustedfirmware.org>, hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>, mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>, olivier.deprez--- via Tf-openci <tf-openci(a)lists.trustedfirmware.org> Subject: Re: [Hafnium] Re: Gerrit scheduled maintenance: 8th November 8-12 UTC Hi Saheer, On 11/9/25 00:19, Saheer Babu via Hafnium wrote: > Hi > > Just wanted to let you all know that maintenance was done in the morning and site is back to normal. I'm getting a 403 from here: $ curl --show-headers https://review.trustedfirmware.org/ HTTP/2 403 server: awselb/2.0 date: Mon, 10 Nov 2025 10:14:55 GMT content-type: text/html content-length: 118 <html> <head><title>403 Forbidden</title></head> <body> <center><h1>403 Forbidden</h1></center> </body> </html> Same for git.trustedfirmware.org which makes the OP-TEE CI fail: https://github.com/OP-TEE/optee_os/actions/runs/19226835413/job/54955917815… Regards, -- Jerome > > Thanks, > Saheer > > From: Saheer Babu <Saheer.Babu(a)arm.com> > Date: Thursday, 30 October 2025 at 16:13 > To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>, tf-rmm(a)lists.trustedfirmware.org <tf-rmm(a)lists.trustedfirmware.org>, hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>, mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>, olivier.deprez--- via Tf-openci <tf-openci(a)lists.trustedfirmware.org> > Subject: Gerrit scheduled maintenance: 8th November 8-12 UTC > Hi All, > > We will be performing maintenance activity on review.trustedfirmware.org and service will be unavailable on 8th November between 8 AM-11 AM UTC. > > Best regards, > > Saheer >

4 months, 3 weeks

1
0
0 0

FW: CI infrastructure scheduled maintenance: 12th Sep 2025

by Joanna Farley

FYI From: Saheer Babu via Tf-openci <tf-openci(a)lists.trustedfirmware.org> Date: Wednesday, 10 September 2025 at 15:17 To: tf-openci(a)lists.trustedfirmware.org <tf-openci(a)lists.trustedfirmware.org> Subject: [Tf-openci] CI infrastructure scheduled maintenance: 12th Sep 2025 Hi all, We will be performing upgrade of the clusters hosting review.trustedfirmware.org and ci.trustedfirmware.org on Friday, 12th Sep 2025 at 16:00 GMT+1. During this maintenance window, both services will be unavailable for approximately 4 hours. A follow-up email will be sent once the services are fully restored. Best regards, Saheer 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. -- Tf-openci mailing list -- tf-openci(a)lists.trustedfirmware.org To unsubscribe send an email to tf-openci-leave(a)lists.trustedfirmware.org

4 months, 3 weeks

2
3
0 0

Security backports for v2.28

by Matt Bauman

Hello all, I know that v2.28.10 is EOL, but I've been working on bringing security bug fixes to our distribution of it as part of my work in shoring up the Julia package ecosystem. I've largely leaned on the Debian security team's work thus far; they have the much harder task of supporting 2.16.9 for bullseye (security) and have done great work in bringing that version up to date through CVE-2025-52497. I've re-landed their backport patches against v2.28.10; these can be found on our build tree [1] or my fork [2]: 1. https://github.com/JuliaPackaging/Yggdrasil/tree/54c5a3e8e72899a3a778d8617f… 2. https://github.com/Mbed-TLS/mbedtls/compare/v2.28.10...mbauman:mbedtls:v2.2… Now I'm faced with the daunting prospect of last week's CVE-2025-54764 and CVE-2025-59438. These are *much* larger changesets. Has anyone else begun tackling this? I very much appreciated the guidance that’s included in the advisory itself, but I'm guessing there may be others in our situation... and I came here looking to see if anyone had begun talking about this (or working on it) yet. Best, Matt

4 months, 3 weeks

2
2
0 0

Question regarding mbedtls 3.6.0 conformance to IEC 62351-3:2023

by Tommaso Mancini

Hello, I am writing to you to ask if you have any available documentation you can share regarding mbedtls's conformance to IEC 62351-3:2023. For example: Do you know of any users which have implemented the library in systems that reached IEC 62351-3:2023 certification? Do you have a list of features mapped to the IEC 62351-3:2023 standard requirements? Perhaps a PICS template? Thank you in advance and apologies if this is the wrong channel for this kind of question. Kind Regards, Tommaso Mancini [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.

5 months

1
0
0 0

MBEDTLS_ERR_CTR_DRBG_ENTROPY_SOURCE_FAILED

by Кристиян Ценов

5 months

1
0
0 0

Re: TrustedFirmware.org - Check for MbedTLS License/Royality fee for commercial usage

by Carina Tsai

To whom it may concern, Our engineering team is using the Mbed TLS library in our wifi range extenders sold on markets and adhere to the licensing terms outlined in the sourcecode and docs. Thanks to Shaun’s guideline, it would be no royalty if we adhere to the licensing terms. Is there any other cost required for us to use the Mbed TLS library in our wifi range extenders, adhering to the licensing terms outlined in the sourcecode and docs? Thank you Carina From: Shaun Longhorn <shaun.longhorn(a)linaro.org<mailto:shaun.longhorn@linaro.org>> Sent: Tuesday, September 30, 2025 7:08 PM To: Ken Chen <Ken.Chen(a)netgear.com<mailto:Ken.Chen@netgear.com>> Cc: enquiries(a)trustedfirmware.org<mailto:enquiries@trustedfirmware.org> Subject: Re: TrustedFirmware.org - Check for MbedTLS License/Royality fee for commercial usage External Email. Be cautious clicking attachments and links. Report suspicious to reportphishing(a)netgear.com<mailto:reportphishing@netgear.com>. Hi Ken, I'm the Community Manager at Trusted Firmware. I can't advise you directly on your licensing situation but I can point you towards the documentation. Mbed TLS is an open source community project and no royalty is required. You must adhere to the licensing terms outlined in the sourcecode and docs: https://github.com/Mbed-TLS/mbedtls?tab=readme-ov-file#license<https://urldefense.com/v3/__https:/github.com/Mbed-TLS/mbedtls?tab=readme-o…> https://mbed-tls.readthedocs.io/en/latest/kb/licensing/<https://urldefense.com/v3/__https:/mbed-tls.readthedocs.io/en/latest/kb/lic…> You can also reach out to the Mbed-TLS community on the following public mailing list. https://lists.trustedfirmware.org/mailman3/lists/mbed-tls.lists.trustedfirm…<https://urldefense.com/v3/__https:/lists.trustedfirmware.org/mailman3/lists…> I should highlight our optional memberships for Trusted Firmware detailed on this page. https://www.trustedfirmware.org/join/<https://urldefense.com/v3/__https:/www.trustedfirmware.org/join/__;!!JNtdCR…> membership has a number of benefits detailed in the slides. It could be beneficial in terms of lab testing and project visibility. If you have an interest we can arrange a call with the Co-Chairs and discuss benefits in more detail. Thanks, Shaun Community Manager On Tue, 30 Sept 2025 at 09:20, 'Ken Chen' via TFenquiries <enquiries(a)trustedfirmware.org<mailto:enquiries@trustedfirmware.org>> wrote: Dear Sir/Madam, I am reaching out to inquire about the licensing terms and any potential royalty fees associated with using the Mbed TLS library in our commercial products. I was unable to find a specific contact point for this type of query. Could you kindly forward this message to the appropriate person or team for further discussion? Thank you for your assistance. Best regards Ken This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.

5 months, 1 week

5
13
0 0

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.

5 months, 2 weeks

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.

5 months, 2 weeks

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…

6 months

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

6 months, 3 weeks

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

6 months, 4 weeks

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

7 months, 1 week

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

7 months, 3 weeks

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.

8 months

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

8 months

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>

8 months, 3 weeks

1
0
0 0

Strategic Financing & Brokerage Collaboration Opportunity

by LIAM GILL

We are pleased to introduce Velositi Consultancy Group, a Finnish-owned brokerage and consultancy firm headquartered in Ontario, Canada. As the exclusive representative of leading financial institutions across Oman, Saudi Arabia, and Dubai, we offer customized financing solutions globally. Through our partners, we provide loan facilities at a competitive 3% annual interest, featuring a 2-year grace period and no physical collateral—a unique offer tailored for today’s business environment. This opportunity is extended especially to recognized business leaders like yourself. Your recent listing by your country’s Chamber of Commerce as “Reliable to do business with” during the Saudi Business Summit highlights the potential for meaningful collaboration. Beyond direct financing, we also welcome broker partnerships for referring businesses in need of funding. We would be pleased to discuss how we can support your growth and financial objectives. Warm regards, Liam Gill Chairman, Business Development Velositi Consultancy Group 300 John Street, Suite 506, Thornhill, ON L3T 6M8, Canada LIAM GILL 300 John Street, Suite 506 , ON , Thornhill , L3T 6M8 Unsubscribe ( https://u45460243.ct.sendgrid.net/wf/unsubscribe?upn=u001.AzuRT3u7SiTsBx5mQ… ) - Unsubscribe Preferences ( https://u45460243.ct.sendgrid.net/wf/unsubscribe?upn=u001.AzuRT3u7SiTsBx5mQ… )

8 months, 3 weeks

1
0
0 0

Mbed TLS 4.0.0-beta & TF-PSA-Crypto 1.0.0-beta releases.

by Minos Galanakis

I am happy to announce the joint-release of Mbed TLS 4.0.0-beta & TF-PSA-Crypto 1.0.0-beta PSA-Crypto now lives in its own repository while TLS and X.509 remain in Mbed TLS. This beta release breaks compatibility with earlier versions of Mbed TLS. Please do not use it in production. It’s intended for the community to verify codebase integrations against the split and API changes, and for early adopters to experiment and provide feedback. For full details, please see the release pages: Mbed TLS 4.0.0-beta: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.0.0-beta TF-PSA-Crypto 1.0.0-beta: https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.0.0-…

9 months

1
0
0 0

[Mbed-tls-announce] Mbed TLS 4.0.0-beta & TF-PSA-Crypto 1.0.0-beta

by Minos Galanakis via Mbed-tls-announce

I am happy to announce the joint-release of Mbed TLS 4.0.0-beta & TF-PSA-Crypto 1.0.0-beta PSA-Crypto now lives in its own repository while TLS and X.509 remain in Mbed TLS. This beta release breaks compatibility with earlier versions of Mbed TLS. Please do not use it in production. It’s intended for the community to verify codebase integrations against the split and API changes, and for early adopters to experiment and provide feedback. For full details, please see the release pages: Mbed TLS 4.0.0-beta: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.0.0-beta TF-PSA-Crypto 1.0.0-beta: https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.0.0-… 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] Mbed TLS 3.6.4 Released

by Minos Galanakis via Mbed-tls-announce

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

imx-secure-enclave with mbedtls 2.28.9

by kavitha bk

Hi We are using mbedtls 2.28.9 and want to offload crypto operations to HSM from NXP imx-secure-enclave. is the below approach correct or please suggest alternate approaches if any? 1.Transition all apis from traditional apis to psa in modules Use PSA crypto module https://github.com/Mbed-TLS/mbedtls/blob/development/docs/psa-transition.md 2. Integrate PSA module with imx-secure-enclave in our custom mbedtls 3. All modules will use custom mbedtls which will internally offload crypto operations to HSM or Do you recommend to use MBEDTLS_PK_RSA_ALT_SUPPORT? and implement the key creation/signing/export of public key operations ? Thanks, Kavitha

9 months, 3 weeks

2
2
0 0

Mbed TLS information request

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>

9 months, 4 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

10 months

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

10 months, 1 week

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!

10 months, 1 week

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

10 months, 1 week

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

10 months, 2 weeks

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

10 months, 2 weeks

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

10 months, 2 weeks

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>

10 months, 3 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

11 months, 1 week

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

1 year

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

1 year

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

1 year

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

1 year

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

1 year, 1 month

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

1 year, 1 month

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

1 year, 1 month

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

1 year, 2 months

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

1 year, 2 months

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,

1 year, 2 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

1 year, 2 months

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]

1 year, 2 months

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

1 year, 2 months

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.

1 year, 2 months

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]

1 year, 2 months

2
1
0 0

Request for Assistance with Iterative Loading and Verification of Built-in Certificates in Mbed TLS

by xiaobing wang

Dear Mbed TLS Support Team, I am currently working on a project using Mbed TLS version 3.6 on FreeRTOS, and I am encountering an issue with handling multiple CA certificates during the TLS handshake process. My device has a set of built-in certificates, and I need to try each certificate one by one to establish a successful connection to my server. However, I am facing difficulties in this process. ### System Information: - **Mbed TLS version**: 3.6 - **Operating System**: FreeRTOS - **Configuration**: Default - **Compiler and Options**: N/A (using default configuration) ### Expected Behavior: The first certificate (e.g., `cdotroot.cer`) cannot be verified by Mbed TLS, while the correct certificate should successfully establish a connection. ### Actual Behavior: Both the incorrect and correct CA certificates fail to establish a connection successfully. ### Steps to Reproduce: Here is a sample of my code: ```c static int load_and_verify_certificates(int conn_id, uint8_t *cert_buffer, size_t buffer_size) { int ret; bool connection_established = false; uint32_t cert_index = 0; while (!connection_established && cert_index < MAX_CERT_COUNT) { size_t cert_size = buffer_size; // Free and initialize the certificate context mbedtls_x509_crt_free(&cacert[conn_id]); mbedtls_x509_crt_init(&cacert[conn_id]); // Load the built-in certificate ret = try_built_in_certificate(cert_buffer, &cert_size, cert_index); if (ret == CERT_ERR_INDEX_OUT_OF_RANGE) { break; } if (ret != CERT_SUCCESS) { cert_index++; continue; } // Parse the certificate cert_buffer[cert_size] = '\0'; ret = mbedtls_x509_crt_parse(&cacert[conn_id], cert_buffer, cert_size + 1); if (ret < 0) { cert_index++; continue; } // Set the certificate chain mbedtls_ssl_conf_ca_chain(&conf[conn_id], &cacert[conn_id], NULL); // Perform the TLS handshake ret = mbedtls_ssl_handshake(&ssl[conn_id]); if (ret == 0) { uint32_t flags = mbedtls_ssl_get_verify_result(&ssl[conn_id]); if (flags == 0) { connection_established = true; // Cache the certificate cache_certificate(cert_buffer, cert_size, cert_index); break; } } else { LOGD("Failed to perform handshake with certificate index %d, error: -0x%x\n", cert_index, -ret); } // Reset the SSL session ret = mbedtls_ssl_session_reset(&ssl[conn_id]); if (ret != 0) { LOGD("Failed to reset SSL session, error: -0x%x\n", -ret); return ret; } cert_index++; } return connection_established ? 0 : -1; } ``` ### Additional Information: Here are the logs: ``` Reading certificate 'cdotroot.cer' at address 0x08100650, size: 1348 Failed to perform handshake with certificate index 0, error: -0x2700 Reading certificate 'digicertroot.cer' at address 0x08100B94, size: 1360 Failed to perform handshake with certificate index 1, error: -0x7300 ... ``` I suspect that the issue may be related to the limited RAM space available on my device. I am looking for guidance on how to properly iterate through and verify the built-in certificates within these constraints. Any suggestions or best practices for handling multiple certificates in such an environment would be greatly appreciated. Thank you for your assistance. Best regards, [Tony] --- Feel free to replace `[Your Name]` with your actual name before sending the email.

1 year, 3 months

1
0
0 0

How to use a different mbedtls_config.h file?

by Alexander Slatina

Hello, I described an issue I have here: https://github.com/Mbed-TLS/mbedtls/issues/9867 During compilation it compiles with the wrong mbedtls_config.h even though I set up this part in my CMakeLists.txt: #MbedTLS default START # 1. MbedTLS custom config setup set(MBEDTLS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/mbedtls) set(MBEDTLS_CONFIG_FILE "${CMAKE_CURRENT_SOURCE_DIR}/mbedtls_config.h") add_compile_definitions( MBEDTLS_CONFIG_FILE="${MBEDTLS_CONFIG_FILE}" MBEDTLS_USER_CONFIG_FILE="${MBEDTLS_CONFIG_FILE}" ) set(ENABLE_TESTING OFF CACHE BOOL "Disable mbedtls testing" FORCE) set(ENABLE_PROGRAMS OFF CACHE BOOL "Disable mbedtls programs" FORCE) set(MBEDTLS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/mbedtls) # Add mbedtls build add_subdirectory(${MBEDTLS_DIR}) #MbedTLS END There’s more information on the GitHub link. Thank you in advance. Alex

1 year, 3 months

1
0
0 0

TF-PSA-Crypto

by Janos Follath

Dear Mbed TLS users, Mbed TLS has contained the reference implementation of the PSA Crypto API since the early days of the standard. This implementation was experimental at first, but over years of development it reached maturity, and the experimental status was removed three years ago (in version 3.6.1.). Shortly after that, in 2022, the TF-PSA-Crypto<https://github.com/Mbed-TLS/TF-PSA-Crypto> repository was created just for the PSA Crypto API implementation to make it more accessible for users only interested in that. This repository was only a mirror of the main one and the development of the PSA Crypto API implementation remained integral part of Mbed TLS. In the background, work has been started to make this repository the place where the development of the PSA Crypto API reference implementation happens. This work has finally been completed and from now on TF-PSA-Crypto<https://github.com/Mbed-TLS/TF-PSA-Crypto> is ready to receive contributions, bug reports and enhancement requests. TF-PSA-Crypto<https://github.com/Mbed-TLS/TF-PSA-Crypto> will now be the development repository for the PSA Crypto reference implementation. Mbed TLS will continue to rely on TF-PSA-Crypto<https://github.com/Mbed-TLS/TF-PSA-Crypto> and will be using it as a submodule. Many thanks, Janos Follath Mbed TLS developer

1 year, 3 months

1
0
0 0

advice on mbedtls_ssl_context change between v2.16.1 and 3.6.2

by Daniel Webb

Hi, Can you give me a little advice on how v3 works? I've updated our mbed library from 2.16.1 to 3.6.2 which was mostly a very smooth experience, thanks. The one question in my mind relates to making p_bio private in mbedtls_ssl_context *I used to free it before calling mbedtls_ssl_free - is it ok to skip this now? ie:* //mbedtls_net_free((mbedtls_net_context *) m_ssl.p_bio); mbedtls_ssl_free(&m_ssl); *I also used to poll it before calling mbedtls_ssl_close_notify - is ok to skip this now? ie:* //if(mbedtls_net_poll((mbedtls_net_context *) m_ssl.p_bio, MBEDTLS_NET_POLL_WRITE, 0) < 0) // return; int ret; while((ret = mbedtls_ssl_close_notify(&m_ssl)) < 0) { if(ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE) return; } It all seems to run just fine like this, but I could really do with some confidence boosting validation of my cavalier commenting. Thank you Daniel

1 year, 3 months

1
1
0 0

Integrating Mbed TLS with LWIP

by Bas Prins

Dear Mbed TLS team, I am trying to integrate Mbed TLS in our platform: - nxp imx rt 1024 CPU (arm based) - FreeRTOS (10.6) - Lwip (2.2) - Mbed TLS (3.6.2) I am using the LWIP port to Mbed TLS and managed to create an client configuration by supplying a google certificate which I created as follows: openssl s_client -showcerts -connect www.google.com:443 </dev/null 2>/dev/null | openssl x509 -outform PEM > google_root_ca.pem PS: using the true random number generator in our CPU as the entropy source for Mbed TLS. I ran into some issues which I managed to resolve by adding another option in Mbed TLS (found this on a forum which solved the problem): #define MBEDTLS_RSA_C /* required for google's root CA */ #define MBEDTLS_PKCS1_V21 /* required for RSA */ Next I connected our http client to use the TLS configuration and gave it a first spin by trying to send a HTTP GET request to google.com. The TLS handshake failed. I enabled logging in the hope this would give me a direction, but I can't see where things go wrong (until the obvious error -0x7780 (MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE)). Can somebody see what goes wrong on the client side, which results in the server deciding to fail the request? Attached the log and will paste it here in the email. ====================== [2024-12-11 09:08:28] 2024-12-10 12:53:35.612 [Info ] [Http] GET from google.com:443 - / [2024-12-11 09:08:28] 2024-12-10 12:53:35.630 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(1327): The SSL configuration is tls12 only. [2024-12-11 09:08:28] 2024-12-10 12:53:35.676 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4606): => handshake [2024-12-11 09:08:28] 2024-12-10 12:53:35.678 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:28] 2024-12-10 12:53:35.678 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:28] 2024-12-10 12:53:35.696 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4525): client state: MBEDTLS_SSL_HELLO_REQUEST [2024-12-11 09:08:28] 2024-12-10 12:53:35.718 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:28] 2024-12-10 12:53:35.736 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:28] 2024-12-10 12:53:35.766 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4525): client state: MBEDTLS_SSL_CLIENT_HELLO [2024-12-11 09:08:28] 2024-12-10 12:53:35.792 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(919): => write client hello [2024-12-11 09:08:28] 2024-12-10 12:53:35.820 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(486): dumping 'client hello, random bytes' (32 bytes) [2024-12-11 09:08:28] 2024-12-10 12:53:35.848 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(486): 0000: 7b 5a 55 53 71 4d 5d ec 7e 88 19 f8 fc b7 72 b4 {ZUSq M].~.....r. [2024-12-11 09:08:28] 2024-12-10 12:53:35.878 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(486): 0010: d1 7e 13 df 21 b8 b6 3f 38 36 d4 63 19 f4 27 89 .~..! ..?86.c..'. [2024-12-11 09:08:28] 2024-12-10 12:53:35.904 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(511): dumping 'session id' (0 bytes) [2024-12-11 09:08:28] 2024-12-10 12:53:35.930 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(369): client hello, add ciphersuite: c02b, TLS-ECDHE-ECDSA-WITH-AES -128-GCM-SHA256 [2024-12-11 09:08:28] 2024-12-10 12:53:35.962 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(387): adding EMPTY_RENEGOTIATION_INFO_SCSV [2024-12-11 09:08:28] 2024-12-10 12:53:35.988 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(396): client hello, got 2 cipher suites [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(230): client hello, adding supported_groups extension [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(249): got supported group(0017) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(281): NamedGroup: secp256r1 ( 17 ) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(249): got supported group(0018) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(281): NamedGroup: secp384r1 ( 18 ) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(301): dumping 'Supported groups extension' (6 bytes) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(301): 0000: 00 04 00 17 00 18 ..... . [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(9593): adding signature_algorithms extension [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(9613): got signature scheme [403] ecdsa_secp256r1_sha256 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(9622): sent signature scheme [403] ecdsa_secp256r1_sha256 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(9613): got signature scheme [401] rsa_pkcs1_sha256 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(9622): sent signature scheme [401] rsa_pkcs1_sha256 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls12_client.c(105): client hello, adding supported_point_formats extension [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(688): client hello, total extension length: 26 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(690): dumping 'client hello extensions' (26 bytes) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(690): 0000: 00 1a 00 0a 00 06 00 04 00 17 00 18 00 0d 00 06 ..... ........... [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(690): 0010: 00 04 04 03 04 01 00 0b 00 02 ..... ..... [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2783): => write handshake message [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2943): => write record [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3027): output record: msgtype = 22, version = [3:3], msglen = 75 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): dumping 'output record sent to network' (80 bytes) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): 0000: 16 03 03 00 4b 01 00 00 47 03 03 7b 5a 55 53 71 ....K.. .G..{ZUSq [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): 0010: 4d 5d ec 7e 88 19 f8 fc b7 72 b4 d1 7e 13 df 21 M].~... ..r..~..! [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): 0020: b8 b6 3f 38 36 d4 63 19 f4 27 89 00 00 04 c0 2b ..?86.c ..'.....+ [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): 0030: 00 ff 01 00 00 1a 00 0a 00 06 00 04 00 17 00 18 ....... ......... [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): 0040: 00 0d 00 06 00 04 04 03 04 01 00 0b 00 02 01 00 ....... ......... [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3080): <= write record [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2904): <= write handshake message [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(1012): <= write client hello [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:28] 2024-12-10 12:53:36.008 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2367): message length: 80, out_left: 80 [2024-12-11 09:08:28] 2024-12-10 12:53:36.044 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2374): ssl->f_send() returned 80 (-0xffffffb0) [2024-12-11 09:08:28] 2024-12-10 12:53:36.082 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2401): <= flush output [2024-12-11 09:08:28] 2024-12-10 12:53:36.114 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4525): client state: MBEDTLS_SSL_SERVER_HELLO [2024-12-11 09:08:28] 2024-12-10 12:53:36.142 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls12_client.c(1193): => parse server hello [2024-12-11 09:08:28] 2024-12-10 12:53:36.170 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(4189): => read record [2024-12-11 09:08:28] 2024-12-10 12:53:36.196 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2155): => fetch input [2024-12-11 09:08:28] 2024-12-10 12:53:36.226 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2295): in_left: 0, nb_want: 5 [2024-12-11 09:08:28] 2024-12-10 12:53:36.256 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2315): in_left: 0, nb_want: 5 [2024-12-11 09:08:28] 2024-12-10 12:53:36.284 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4617): <= handshake [2024-12-11 09:08:28] 2024-12-10 12:53:36.314 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:29] 2024-12-10 12:53:36.344 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:29] 2024-12-10 12:53:36.374 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:29] 2024-12-10 12:53:36.400 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:29] 2024-12-10 12:53:36.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:29] 2024-12-10 12:53:36.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:29] 2024-12-10 12:53:37.380 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:29] 2024-12-10 12:53:37.382 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:30] 2024-12-10 12:53:37.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:30] 2024-12-10 12:53:37.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:30] 2024-12-10 12:53:38.392 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:30] 2024-12-10 12:53:38.394 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:31] 2024-12-10 12:53:38.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:31] 2024-12-10 12:53:38.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:31] 2024-12-10 12:53:39.346 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4606): => handshake [2024-12-11 09:08:31] 2024-12-10 12:53:39.346 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:31] 2024-12-10 12:53:39.348 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:31] 2024-12-10 12:53:39.348 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4525): client state: MBEDTLS_SSL_SERVER_HELLO [2024-12-11 09:08:31] 2024-12-10 12:53:39.350 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls12_client.c(1193): => parse server hello [2024-12-11 09:08:32] 2024-12-10 12:53:39.350 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(4189): => read record [2024-12-11 09:08:32] 2024-12-10 12:53:39.352 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2155): => fetch input [2024-12-11 09:08:32] 2024-12-10 12:53:39.378 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2295): in_left: 0, nb_want: 5 [2024-12-11 09:08:32] 2024-12-10 12:53:39.404 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2315): in_left: 0, nb_want: 5 [2024-12-11 09:08:32] 2024-12-10 12:53:39.430 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2318): ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) [2024-12-11 09:08:32] 2024-12-10 12:53:39.460 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2340): <= fetch input [2024-12-11 09:08:32] 2024-12-10 12:53:39.490 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3855): dumping 'input record header' (5 bytes) [2024-12-11 09:08:32] 2024-12-10 12:53:39.516 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3855): 0000: 15 03 03 00 02 ..... [2024-12-11 09:08:32] 2024-12-10 12:53:39.542 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3857): input record: msgtype = 21, version = [0x303], msglen = 2 [2024-12-11 09:08:32] 2024-12-10 12:53:39.570 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2155): => fetch input [2024-12-11 09:08:32] 2024-12-10 12:53:39.598 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2295): in_left: 5, nb_want: 7 [2024-12-11 09:08:32] 2024-12-10 12:53:39.630 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2315): in_left: 5, nb_want: 7 [2024-12-11 09:09:51] 2024-12-10 12:53:39.656 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2318): ssl->f_recv(_timeout)() returned 2 (-0xfffffffe) [2024-12-11 09:09:51] 2024-12-10 12:53:39.688 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2340): <= fetch input [2024-12-11 09:09:51] 2024-12-10 12:53:39.722 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3964): dumping 'input record from network' (7 bytes) [2024-12-11 09:09:52] 2024-12-10 12:53:39.756 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3964): 0000: 15 03 03 00 02 02 28 ......( [2024-12-11 09:09:55] 2024-12-10 12:53:39.782 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(5092): got an alert message, type: [2:40] [2024-12-11 09:09:55] 2024-12-10 12:53:39.810 [Debug] [Http] 1 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(5099): is a fatal alert message (msg 40) [2024-12-11 09:09:55] 2024-12-10 12:54:59.004 [Debug] [Http] 1 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(4244): mbedtls_ssl_handle_message_type() returned -30592 (-0x7780) [2024-12-11 09:09:55] 2024-12-10 12:54:59.036 [Debug] [Http] 1 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls12_client.c(1197): mbedtls_ssl_read_record() returned -30592 (-0x7780) [2024-12-11 09:09:55] 2024-12-10 12:54:59.062 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4617): <= handshake [2024-12-11 09:09:55] 2024-12-10 12:54:59.094 [Debug] [External] mbedtls_ssl_handshake failed: -30592 [2024-12-11 09:09:55] 2024-12-10 12:55:02.000 [Debug] [Http] Download failed: httpc_result 4, srv_resp 0, err -15 ====================== Many thanks in advance! Best regards, Bas

1 year, 3 months

1
0
0 0

C448 according RFC7748?

by Tom Strolch

Hello all, I want to use mbedtls-functions for "Shared Secret" according ECDH with C448. First I want to check the test vectors mentioned in RFC7748 (chapter 6.2). But it fails in function mbedtls_ecdh_compute_shared(...) with return value -0x4C80 MBEDTLS_ERR_ECP_INVALID_KEY (please see code below) But up to now I can't find the root cause. Is there a similar example available? Regards, Tom // Alice's private key static const unsigned char alice_private_key[] = { 0x77, 0x07, 0x6d, 0x0a, 0x73, 0x18, 0xa5, 0x7d, 0x3c, 0x16, 0xc1, 0x72, 0x51, 0xb2, 0x66, 0x45, 0xdf, 0x4c, 0x2f, 0x87, 0xeb, 0xc0, 0x99, 0x2a, 0xb1, 0x77, 0xfb, 0xa5, 0x1d, 0xb9, 0x2c, 0x2a }; // Bob's private key static const unsigned char bob_private_key[] = { 0x5d, 0xab, 0x08, 0x7e, 0x62, 0x4a, 0x8a, 0x4b, 0x79, 0xe1, 0x7f, 0x8b, 0x83, 0x80, 0x0e, 0xe6, 0x6f, 0x3b, 0xb1, 0x29, 0x26, 0x18, 0xb6, 0xfd, 0x1c, 0x2f, 0x8b, 0x27, 0xff, 0x88, 0xe0, 0xeb }; int main() { mbedtls_ecdh_context ecdh; unsigned char shared_secret[32]; size_t olen; int ret; mbedtls_ecdh_init(&ecdh); // Load Bob's private key ret = mbedtls_ecp_group_load(&ecdh.grp, MBEDTLS_ECP_DP_CURVE25519); if (ret != 0) { printf("Failed to load group\n"); return 1; } ret = mbedtls_mpi_read_binary(&ecdh.d, bob_private_key, sizeof(bob_private_key)); if (ret != 0) { printf("Failed to read private key\n"); return 1; } // Compute the shared secret ret = mbedtls_ecdh_compute_shared(&ecdh.grp, &ecdh.z, &ecdh.Qp, &ecdh.d, mbedtls_ctr_drbg_random, NULL); if (ret != 0) { printf("Failed to compute shared secret\n"); return 1; } ... Test vector: Alice's private key, a: 9a8f4925d1519f5775cf46b04b5800d4ee9ee8bae8bc5565d498c28d d9c9baf574a9419744897391006382a6f127ab1d9ac2d8c0a598726b Alice's public key, X448(a, 5): 9b08f7cc31b7e3e67d22d5aea121074a273bd2b83de09c63faa73d2c 22c5d9bbc836647241d953d40c5b12da88120d53177f80e532c41fa0 Bob's private key, b: 1c306a7ac2a0e2e0990b294470cba339e6453772b075811d8fad0d1d 6927c120bb5ee8972b0d3e21374c9c921b09d1b0366f10b65173992d Bob's public key, X448(b, 5): 3eb7a829b0cd20f5bcfc0b599b6feccf6da4627107bdb0d4f345b430 27d8b972fc3e34fb4232a13ca706dcb57aec3dae07bdc1c67bf33609 Their shared secret, K: 07fff4181ac6cc95ec1c16a94a0f74d12da232ce40a77552281d282b b60c0b56fd2464c335543936521c24403085d59a449a5037514a879d

1 year, 3 months

1
0
0 0

Migrate LWIP mbed TLS port to Mbed TLS 3.6.2 (or later)

by Bas Prins

Dear Mbed TLS team, I am trying to integrate Mbed TLS in our platform: - nxp imx rt 1024 CPU (arm based) - FreeRTOS (10.6) - Lwip (2.2) - Mbed TLS (3.6.2) LWIP supports Mbed TLS when adding defines in their configuration: /* ---------- TLS ------------------------- */ #define LWIP_ALTCP 1 #define LWIP_ALTCP_TLS 1 #define LWIP_ALTCP_TLS_MBEDTLS 1 But, unfortunately this supports an older version of Mbed TLS (I believe 2.2.x). When I try to compile against the Mbed TLS 3.6.2 libraries, I get a bunch of compiler warnings / errors. Most of them are mentioned in the migration guide, but even then, I have a hard time figuring out how to resolve them "the right way". 1. Private fields The migration guide <https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-3.6/docs/3.0-migration-gui…> explains that most structs are now considered private. 1.1: The altcp_mbed module in LWIP relies on the *out_left* field of the *ssl context* struct. /* calculate TLS overhead part to not send it to application */ overhead = state->overhead_bytes_adjust + state->ssl_context.out_left; I am correct that this field is simply not exposed through accessor functions? I can find functions like mbedtls_ssl_get_avail, so I would expect something like mbedtls_ssl_get_bytes_to_write or something like that? 1.2: The altcp_mbed module in LWIP relies on the *start* field of the *ssl session* struct. err_t altcp_tls_set_session(struct altcp_pcb *conn, struct altcp_tls_session *session) { if (session && conn && conn->state) { altcp_mbedtls_state_t *state = (altcp_mbedtls_state_t *)conn->state; int ret = -1; * if (session->data.start)* ret = mbedtls_ssl_set_session(&state->ssl_context, &session->data); return ret < 0 ? ERR_VAL : ERR_OK; } return ERR_ARG; } I also don't know how to obtain this field "the right way". I know this is a bad idea, but it's all I got if (session->data.*private_start)* ... 2. parse key expects a RNG function This is also explained in the migration guide: *Some functions gained an RNG parameterThis affects users of the following functions: `mbedtls_ecp_check_pub_priv()`,`mbedtls_pk_check_pair()`, `mbedtls_pk_parse_key()`, and`mbedtls_pk_parse_keyfile()`.You now need to pass a properly seeded, cryptographically secure RNG whencalling these functions. It is used for blinding, a countermeasure againstside-channel attacks.* Can you please give me some guidance here? I looked for examples in Mbed TLS repo and ended up with this (bold parts are added, using the key_app.c in your repo as leading example): * mbedtls_entropy_context entropy; mbedtls_ctr_drbg_context ctr_drbg; mbedtls_entropy_init(&entropy); mbedtls_ctr_drbg_init(&ctr_drbg); if ((ret = mbedtls_ctr_drbg_seed( &ctr_drbg, mbedtls_entropy_func, &entropy, privkey, privkey_len)) != 0) { // TODO: handle error } * ret = mbedtls_pk_parse_key( conf->pkey, privkey, privkey_len, privkey_pass, privkey_pass_len, *mbedtls_ctr_drbg_random, &ctr_drbg*); 3. The altcp_mbed module in LWIP relies on mbedtls_ssl_flush_output The altcp_mbed module had an include on ssl internal. #include "mbedtls/ssl_internal.h" /* to call mbedtls_flush_output after ERR_MEM */ This header seems no longer part of the library. But the prototype of the function is now part of ssl_misc.h, but I don't think I am supposed to rely on this header either. I have a couple of options: - ignore the compiler warning /home/dev_container/app/thirdparty/lwip/src/apps/altcp_tls/altcp_tls_mbedtls.c:535:5: warning: implicit declaration of function 'mbedtls_ssl_flush_output'; did you mean 'mbedtls_ssl_tls_prf'? [-Wimplicit-function-declaration] 535 | mbedtls_ssl_flush_output(&state->ssl_context); - copy paste the declaration in the LWIP source file - Or.... don't flush any buffers managed by Mbed TLS in the first place? For the last one, I could really use your input. Can you say anything meaningful about the flush (line in bold) In the below function, Is it mandatory? Or can I trust the Mbed TLS will flush the output buffer whenever it needs to get flushed? /** Sent callback from lower connection (i.e. TCP) * This only informs the upper layer the number of ACKed bytes. * This now take care of TLS added bytes so application receive * correct ACKed bytes. */ static err_t altcp_mbedtls_lower_sent(void *arg, struct altcp_pcb *inner_conn, u16_t len) { struct altcp_pcb *conn = (struct altcp_pcb *)arg; LWIP_UNUSED_ARG(inner_conn); /* for LWIP_NOASSERT */ if (conn) { int overhead; u16_t app_len; altcp_mbedtls_state_t *state = (altcp_mbedtls_state_t *)conn->state; LWIP_ASSERT("state", state != NULL); LWIP_ASSERT("pcb mismatch", conn->inner_conn == inner_conn); /* calculate TLS overhead part to not send it to application */ mbedtls_ssl_get_bytes_avail(&state->ssl_context); overhead = state->overhead_bytes_adjust + state->ssl_context.private_out_left; if ((unsigned)overhead > len) { overhead = len; } /* remove ACKed bytes from overhead adjust counter */ state->overhead_bytes_adjust -= len; /* try to send more if we failed before (may increase overhead adjust counter) */ *mbedtls_ssl_flush_output(&state->ssl_context); // Does it make sense this LWIP port is responsible for flushing here??* /* remove calculated overhead from ACKed bytes len */ app_len = len - (u16_t)overhead; /* update application write counter and inform application */ if (app_len) { state->overhead_bytes_adjust += app_len; if (conn->sent) return conn->sent(conn->arg, conn, app_len); } } return ERR_OK; } After applying the changes I mentioned above, the software compiles against Mbed TLS. I haven't dared to run anything, I just want to enjoy this short moment where I have the feeling I achieved something before runtime errors ruin my day :). Many thanks in advance for any reply! Best regards, Bas [image: image.png]

1 year, 3 months

1
0
0 0

MbedTLS 2.5 vs MbedTLS 3.6

by Michael Khoyilar

Hi Team I am investigating the move from MbedTLS 2.25 to 3.6, however, our client uses the 2.25 currently (looks like they prefer to stay with it) and I need to provide convincing proof to move to 3.6 considering the upgrade issues that might arise. Any suggestions here that is convincing proof to do the migration to 3.6? I would appreciate your comments. Thanks Michael

1 year, 3 months

5
5
0 0

Trying to integrate Mbed TLS (3.6) with LWIP (2.x)

by Bas Prins

Dear Mbed TLS team, I am at the early steps of trying to integrate Mbed TLS with LWIP for our project (imx rt 1024 NXP micro, arm M7, running FreeRTOS and LWIP). I understand the basics of TLS, but I am far from an expert. Let me first apologise for the lengthy first email. I am afraid to leave out details. Feel free to skip directly to the end marked with: ============================= My questions: ============================= Some background / translation of how I think it (should) work: From a distance, I understand that LWIP has an abstraction layer on their TCP module, which can be used to integrate Mbed TLS. In fact, LWIP already did this, all I need to do is enable some directives (LWIP_ALTCP_TLS and LWIP_ALTCP_TLS_MBEDTLS). The implemented integration assumes a somewhat older version of Mbed TLS, so I have to adjust a couple to cope with the breaking changes from Mbed TLS 2.x to Mbed TLS 3.6.2. But other than that, integrating Mbed TLS would mean: - figure out which options i want to enable in Mbed TLS - cross compile it for our arm toolchain - extend our build scripts to compile against 3 static Mbed TLS libraries - figure out how to read the CA certificates, and provide them to Mbed TLS - test and fail, and hopefully be man enough to solve the challenges ahead... I haven't achieved much yet, but at least I managed to compile Mbed TLS with our toolchain and recompile our project against the linked libraries. This steps fails though, I get a bunch of linker errors : [100%] Linking CXX executable app.axf /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_msg.c.obj): in function `mbedtls_ssl_encrypt_buf': /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c:1211:(.text.mbedtls_ssl_encrypt_buf+0x1b4): undefined reference to `mbedtls_cipher_auth_encrypt_ext' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_msg.c.obj): in function `mbedtls_ssl_decrypt_buf': /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c:1638:(.text.mbedtls_ssl_decrypt_buf+0x180): undefined reference to `mbedtls_cipher_auth_decrypt_ext' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_msg.c.obj): in function `mbedtls_ssl_transform_free': /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c:6213:(.text.mbedtls_ssl_transform_free+0x14): undefined reference to `mbedtls_cipher_free' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c:6214:(.text.mbedtls_ssl_transform_free+0x1e): undefined reference to `mbedtls_cipher_free' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_tls.c.obj): in function `mbedtls_ssl_transform_init': /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:1028:(.text.mbedtls_ssl_transform_init+0x18): undefined reference to `mbedtls_cipher_init' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:1029:(.text.mbedtls_ssl_transform_init+0x22): undefined reference to `mbedtls_cipher_init' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_tls.c.obj): in function `mbedtls_ssl_get_mode_from_ciphersuite': /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:2453:(.text.mbedtls_ssl_get_mode_from_ciphersuite+0x12): undefined reference to `mbedtls_cipher_info_from_type' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_tls.c.obj): in function `mbedtls_ssl_parse_finished': /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:8680:(.text.mbedtls_ssl_parse_finished+0xac): undefined reference to `mbedtls_ct_memcmp' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_tls.c.obj): in function `ssl_tls12_populate_transform': /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:8878:(.text.ssl_tls12_populate_transform+0xa6): undefined reference to `mbedtls_cipher_info_from_type' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:9136:(.text.ssl_tls12_populate_transform+0x454): undefined reference to `mbedtls_cipher_setup' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:9142:(.text.ssl_tls12_populate_transform+0x476): undefined reference to `mbedtls_cipher_setup' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:9148:(.text.ssl_tls12_populate_transform+0x4a8): undefined reference to `mbedtls_cipher_setkey' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:9155:(.text.ssl_tls12_populate_transform+0x4da): undefined reference to `mbedtls_cipher_setkey' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: CMakeFiles/app.dir/home/dev/app/thirdparty/lwip/src/apps/altcp_tls/altcp_tls_mbedtls.c.obj: in function `altcp_mbedtls_sndbuf': /home/dev/app/thirdparty/lwip/src/apps/altcp_tls/altcp_tls_mbedtls.c:1192:(.text.altcp_mbedtls_sndbuf+0x7e): undefined reference to `mbedtls_ssl_get_max_frag_len' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_tls12_server.c.obj): in function `ssl_parse_client_psk_identity': /home/dev/app/thirdparty/mbedtls/library/ssl_tls12_server.c:3638:(.text.ssl_parse_client_psk_identity+0xb6): undefined reference to `mbedtls_ct_memcmp' The distinct list undefined references of the above: undefined reference to `mbedtls_cipher_auth_encrypt_ext' undefined reference to `mbedtls_cipher_auth_decrypt_ext' undefined reference to `mbedtls_cipher_free' undefined reference to `mbedtls_cipher_init' undefined reference to `mbedtls_cipher_info_from_type' undefined reference to `mbedtls_ct_memcmp' undefined reference to `mbedtls_cipher_setup' undefined reference to `mbedtls_cipher_setup' undefined reference to `mbedtls_cipher_setkey' undefined reference to `mbedtls_cipher_setkey' undefined reference to `mbedtls_ssl_get_max_frag_len' All except the last one are coming from Mbed TSL internally, so I *guess* this means I am missing options? Or maybe I am still having too many? The last one is called from the LWIP integration of Mbed TLS, and I could "sweep this under the carpet" by disabling "MBEDTLS_SSL_MAX_FRAGMENT_LENGTH". But I haven't looked further in what I cause if I do not support "RFC 6066 max_fragment_length extension in SSL" My Mbed TLS configuration: I followed the suggestion of your documentation, and went for a minimal example configuration. Pure on intuition, I went for "config-ccm-psk-dtls1_2.h". Because the file name suggests it brings TSL 1.2 which is basically all I need. I think. I did had to make the following changes in order to be able to compile it: 1. Comment out two defines in order to get rid of module requiring "windows or unix" //#define MBEDTLS_NET_C //#define MBEDTLS_TIMING_C 2. Add a define, again to get rid of the compiler error "require windows or unix" #define MBEDTLS_NO_PLATFORM_ENTROPY After applying these small changes to the include/mbedtls/mbedtls_config.h I was able to cross compile (and link) Mbed TLS with arm-none-eabi toolchain. Once I adjusted the build scripts to lnk against the Mbed TLS static libraries, I finally ended up with the earlier mentioned linker errors. ============================= My questions: ============================= 1. Does my starting point configuration make sense? As mentioned earlier, pure intuition made me try the "config-ccm-psk-dtls1_2.h" configuration example, which after some modifications compiled and produced 3 static libraries. but, this bit in the example header worries me a bit: * Distinguishing features: * - Optimized for small code size, low bandwidth (on an unreliable transport), * and low RAM usage. * - No asymmetric cryptography (no certificates, no Diffie-Hellman key * exchange). * - Fully modern and secure (provided the pre-shared keys are generated and * stored securely). * - Very low record overhead with CCM-8. * - Includes several optional DTLS features typically used in IoT. What does "no asymmetric cryptography" exactly mean? Isn't that the pure basis of TLS altogether? If I want to achieve HTTPS using TLS, is this a good starting point? 2. Undefined references: wrong configuration, or should I supply some of the implementations? As mentioned before, I have quite a few linking errors related to the cipher module. I tried to find answers in the documentation, but came up empty. I assume (again...) that I should be able to get rid of these linking errors by enabling more features in Mbed TLS. But I honestly get lost in #define's. And maybe it's documented somewhere, but I couldn't find it. 3. Root CA provided by me? I assume I *need* to provide at least one root CA for Mbed TLS to be able to verify the public key provided by the server, at some point, right? I would expect some callback I need to implement where such a root CA was read (in my case, i would have to read if from flash). Am I misunderstanding Mbed TLS on this aspect also? Or did I just miss the obvious spot where to Mbed TLS requests a root CA? 4. More examples available for typical microcontroller projects (FreeRTOS/LWIP)? My experience so far is: - Mbed TLS is well documented - LWIP is no longer actively maintained, and lacks documentation in general - Google finds a painful amount of LWIP/TLS integrations which are based on really old implementations of both, which does more harm than good for me - Chat GPT knows everything, even when it doesn't, which is a really great recipe to get on the wrong track... It doesn't seem rather helpful on my integration questions for Mbed TLS/LWIP. Disclaimer: could be that my lack of knowledge is causing gpt to come up with wrong answers of course... I understand that my email is (too?) long, and that the chance somebody will actually find the time to help me out is limited. I expect nothing, I hope for everything :) ANY help is more than welcome. Good references, links to official documentation I missed, or in the best case: answers to my questions/uncertainties. Many thanks in advance. Best regards, Bas

1 year, 3 months

2
1
0 0

Confirm if there is an upgrade to the PKCS#1 V2.2 standard.

by Elva Huang

Dear mbedtls platform, I would like to inquire whether the PKCS#1 standard in the source code of mbedtls V2.28.2 has been upgraded to V2.2. From which version does mbedtls start supporting PKCS#1 v2.2? Looking forward to your reply, thank you. Elva Huang | SW Engineer Tel: 18150372635 Email:elva.huang@robosense.cn<elva.huang(a)robosense.cn> 深圳市 - 南山区 - 速腾聚创产品中心 [image]<http://www.robosense.cn/> [image]<https://www.linkedin.com/company/13232246/admin/>[image]<https://twitter.com/RoboSenseLiDAR>[image]<https://www.facebook.com/RoboSenseLiDAR/>[image]<https://www.youtube.com/channel/UCYCK8j678N6d_ayWE_8F3rQ>

1 year, 4 months

2
1
0 0

How to export mbedtls_snprintf ?

by Gal Rosen

Hi, I am trying to build lief which is dependent on mbedtls as a static library. I am using conan recipe to build using cmake. The build of the library succeeded, however later while trying to build my own application and link with lief I get the following error: LIEF.lib(x509.obj) : error LNK2001: unresolved external symbol mbedtls_snprintf What do I do wrong? Or should I configure something while building the mbedtls library ? Thanks, Gal.

1 year, 4 months

1
0
0 0

Question about contribution of AES hardware support for RISC-V

by Rick Chen

Dear Mbed TLS maintainers, I have surveyed Mbed TLS and know that it has features which can improve AES block cipher performance by hardware instructions instead of SW implementation e.q., AESCE of ARMV8 and AESNI of INTEL. AS far as I know about RISC-V Cryptography extension(Zkne and Zknd), it also supports relevant AES instructions which can accelerate aes key schedule, encryption and decryption process. (https://tools.cloudbear.ru/docs/riscv-crypto-spec-scalar-1.0.0-rc6-20211012…) I want to ask for your opinions and agreement. Is there any willingness to accept this RISC-V accelerated feature idea and contribution to Mbed TLS ? If you agree with it, I would like to prepare a pull request for you to review. Sincerely, Rick

1 year, 5 months

2
1
0 0

Mbed TLS 3.6.2 release

by David Horstmann

Dear Mbed TLS users, We have released Mbed TLS version 3.6.2. This release provides a security fix for an out-of-bounds write vulnerability in the pkwrite module. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.2 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Many thanks, David Horstmann Mbed TLS developer

1 year, 5 months

1
0
0 0

Checking that RSA key and issuer certificate match using mbedTLS 3.x

by Fabian Keil

Hi, I'm currently working on adding mbedTLS 3.x support for Privoxy [0]. Everything seems to be working but I ifdef'ed out the following code in [1] that worked with mbedTLS 2.28.8: /* * Check if key and issuer certificate match */ if (!mbedtls_pk_can_do(&issuer_cert.pk, MBEDTLS_PK_RSA) || mbedtls_mpi_cmp_mpi(&mbedtls_pk_rsa(issuer_cert.pk)->N, &mbedtls_pk_rsa(*issuer_key)->N) != 0 || mbedtls_mpi_cmp_mpi(&mbedtls_pk_rsa(issuer_cert.pk)->E, &mbedtls_pk_rsa(*issuer_key)->E) != 0) { log_error(LOG_LEVEL_ERROR, "Issuer key doesn't match issuer certificate"); ret = -1; goto exit; } As N and E are private now it no longer compiles. Is there a way to implement the check with mbedTLS 3.x? My impression is that the sanity check is overly cautious and we don't have equivalent code for OpenSSL and wolfSSL but I'm curious. Thanks, Fabian [0] <https://www.privoxy.org/> [1] <https://www.privoxy.org/gitweb/?p=privoxy.git;a=blob;f=ssl.c;h=e8007cd9adad…>

1 year, 5 months

2
2
0 0

Client Certificate Request Question

by Michael Reutman

Hello, I'm running into an issue with using Mbed-TLS on an embedded device of ours and I'm curious if anyone would be able to point me in the right direction. If this is the wrong channel for general use questions, let me know and I'll search elsewhere. As a forewarning, I'm still getting my bearings around the nuts and bolts of Mbed-TLS and network security; apologies if I misstate something or jumble things up. Our device uses Mbed-TLS 3.0.0; ideally I'd like to upgrade this to a newer version, but this version was included in a SDK package for our device and I'd like to get some basic functionality proven out first before trying to reintegrate a newer version into the rest of provided code. The current goal is to get our device to serve a web page over HTTPS with TLS. What we currently see is that the initial hello client and server messages are exchanged without issue, but the connection is rejected after the server requests a certificate from the client. In some browsers, this opens a prompt where you can select a given certificate on the machine; in others, it skips this prompt and sends a response back with an empty certificate. In both instances, the server will return an error and deny the connection. This seems like some sort of user configuration error, given your average web page served over HTTPS on the internet avoids making this request. The literature I've been able to find so far also seems to suggest this request is entirely optional. Is there some option I'm overlooking that makes the server skip asking the client for its certificate and lets connection continue on? Michael Reutman Senior Embedded Software Engineer NovaTech Automation 261 Brodhead Rd. Bethlehem, PA 18017 novatechautomation.com<http://www.novatechautomation.com/> | NovaTechLinkedIn<https://www.linkedin.com/company/565017> NovaTech Automation is Net Zero committed. #KeepItCool<https://www.keepitcool.earth/> Receipt of this email implies compliance with our terms and conditions<https://www.novatechautomation.com/email-terms-conditions>.

1 year, 6 months

2
2
0 0

Problem when parsing certificate without Distinguished Name

by Diego Santos

Hi, I'm trying to parse this DER encoded certificate in hex format: 3082018230820128a003020102020900f3b305f55622cfdf300a06082a8648ce3d04030230003020170d3735303130313030303030305a180f34303936303130313030303030305a30003059301306072a8648ce3d020106082a8648ce3d0301070342000458f7e9581748ff9bdd933b655cc0e5552a1248f840658cc221dec2186b5a2fe4641b86ab7590a3422cdbb1000cf97662f27e5910d7569f22feed8829c8b52e0fa38188308185308182060a2b0601040183a25a01010101ff0471306f042508021221026b053094d1112bce799dc8026040ae6d4eb574157929f1598172061f753d9b1b04463044022040712707e97794c478d93989aaa28ae1f71c03af524a8a4bd2d98424948a782302207b61b7f074b696a25fb9e0059141a811cccc4cc28042d9301b9b2a4015e87470300a06082a8648ce3d04030203480030450220143ae4d86fdc8675d2480bb6912eca5e39165df7f572d836aa2f2d6acfab13f8022100831d1979a98f0c4a6fb5069ca374de92f1a1205c962a6d90ad3d7554cb7d9df4 This certificate is part of a simple test for this specification https://github.com/libp2p/specs/blob/master/tls/tls.md I'm using this https://github.com/status-im/nim-mbedtls Nim language library wrapper for mbedtls. I don't know the mbedtls version exactly, but the lib is based on this commit https://github.com/Mbed-TLS/mbedtls/tree/09d23786f6fdcb4dfa88aad30c8767bd27…. In my code I use: proc parseUnverified*(derInput: seq[byte]) = var crt: mbedtls_x509_crt mbedtls_x509_crt_init(addr crt) var ret = mbedtls_x509_crt_parse_der(addr crt, unsafeAddr derInput[0], derInput.len.uint) if ret != 0: raise newException(Exception, "Failed to parse certificate, error code: " & $ret) which is a straightforward version of the C code, but ti fails with: Failed to parse certificate, error code: -9186 [Exception] It seems the problem is because the certificate doesn't have the Distinguished Name set. Does it make sense? If this is really the cause of the problem, is there any workaround? Regards.

1 year, 6 months

1
0
0 0

Need Info : mbedtls_x509_get_sig_alg API

by Satya Prakash Prasad

Hi, We were using old MBed TLS version 2.19.1 and existing trusted CA certificates were working fine in that release. Recently we upgraded to 3.6.0 and see that now certificate parsing is returning -ox262e value from function mbedtls_x509_get_sig_alg cause of which handshake is not even initiated. Can you please let us know what can cause such an issue and remedy the same? Regards, Prakash

1 year, 6 months

1
2
0 0

Looking for suggestions about make Mbed TLS APIs non-secure callable APIs on armv8m

by Lee, William

Hi Mbed TLS, I am looking for some suggestions about make some (or all) Mbed TLS APIs non-secure callable APIs on armv8m. The background is that I am going to have a secure firmware that provides encryption services by building part (or whole) of Mbed TLS into that firmware and make those original mbedtls_x APIs non-secure callable, so the existing non-secure firmware could link those non-secure callable APIs and use them. Some of my thoughts: (1) The easiest way to do it I can think of is just add the attribute "cmse_nonsecure_call" to those APIs' declaration (or use a macro to wrap the attribute for conditional build to not impact others don't want it), but I do not think this modification could be accepted by upstream 🙂. (2) So my another thought is duplicate all header files and put them under another folder, assuming it is my-include folder, then I can do whatever I want to my-include folder, but there is also a problem I can think of: a merge/compare burden between include and my-include folder after I have updated Mbed TLS. I really appreciate other suggestions! Thanks, William

1 year, 6 months

3
3
0 0

Reminder: MBed TLS Tech Forum - US/Europe

by Don Harbin

Hi All, A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum is next Monday at 4:30pm UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Janos know. :) Don

1 year, 6 months

1
0
0 0

Setting ciphersuite causes MBEDTLS_ERR_SSL_ILLEGAL_PARAMETER

by Mbed TLS

My mbedtls client has been working for 2 years. It did what I required and has been stable. However, I now need to force a new server to use my preferred cipher suite. I found the helper function to force the cipher suite here: https://github.com/Mbed-TLS/mbedtls/blob/de4d5b78558666d2e258d95e6c5875f9c7… I added mbedtls_ssl_conf_preference_order(conf, MBEDTLS_SSL_SRV_CIPHERSUITE_ORDER_CLIENT) to the end of the function to force the server to choose my ciphersuite. Prior to this change I called the mbedtls functions in this chronological order: mbedtls_ssl_init(&_ssl); mbedtls_ssl_config_init(&_conf); mbedtls_ctr_drbg_init(&_ctr_drbg); mbedtls_entropy_init(&_entropy); mbedtls_x509_crt_init(&_cacert); mbedtls_pk_init(&_pkey); mbedtls_ctr_drbg_seed mbedtls_ssl_config_defaults mbedtls_ssl_conf_rng mbedtls_ssl_conf_authmode mbedtls_x509_crt_parse_file mbedtls_ssl_conf_ca_chain mbedtls_ssl_setup mbedtls_ssl_set_hostname and then proceed to call: mbedtls_ssl_set_bio mbedtls_ssl_handshake Now: If I call mbedtls_ssl_conf_ciphersuites BEFORE mbedtls_ssl_config_defaults, the ciphersuite list is ignored/seems to get overriden. If I call mbedtls_ssl_conf_ciphersuites AFTER mbedtls_ssl_config_defaults, my ciphersuite list changes are accepted and transmitted (I can see in Wireshark). The server then responds agreeing to use my chosen cipher suite. However, mbedtls_ssl_handshake returns with value -26112, which I have looked up to be MBEDTLS_ERR_SSL_ILLEGAL_PARAMETER. Unfortunately I have no clue what is causing this. Could somebody please advise how this should be done? I can see Client2 example but there are functions I have which are not in there. Client1 seems too simple for me but Client2 seems beyond what I require.

1 year, 6 months

2
5
0 0

Connect using IP address instead of URL "509 - Certificate verification failed, e.g. CRL, CA or signature check failed"

by M M

I am using MbedTLS client code based on this: https://github.com/machinezone/IXWebSocket/blob/master/ixwebsocket/IXSocket… I am connecting to a server via it's URL. However, I would like to connect directly using an IP address returned from running the traceroute command on the URL. So I replaced the URL with the IP address. However, MBedTLS fails on the handshake: https://github.com/machinezone/IXWebSocket/blob/master/ixwebsocket/IXSocket… I get the error: "error in handshake : X509 - Certificate verification failed, e.g. CRL, CA or signature check failed" If I revert back to URL, it works. The IP address does exist. How can I connect using the IP address, instead of the URL?

1 year, 6 months

3
3
0 0

Re: mbedtls and PQC algorithms support

by Raunak Gupta

Micron Confidential Hi, I find that mbed-tls already support LMS, could you please Point to some reference and starting from which version mbedTLS lib version supports LMS? Best Regards, Raunak Get Outlook for iOS<https://aka.ms/o0ukef> Micron Confidential

1 year, 6 months

2
1
0 0

Re: [EXT] RE: Inquiry About PQC Cryptos in embedTLS Library

by Raunak Gupta

Micron Confidential Dear MbedTLS, Can you please help to provide some references for LMS stateful signatures schemes support in MbedTLS, May be something like documentation and github repo link? Unfortunately I am not able to find it online? Thanks, Raunak Get Outlook for iOS<https://aka.ms/o0ukef> Micron Confidential ________________________________ From: Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com> Sent: Tuesday, September 3, 2024 8:48 PM To: Raunak Gupta <raunakgupta(a)micron.com>; enquiries(a)trustedfirmware.org <enquiries(a)trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [EXT] RE: Inquiry About PQC Cryptos in embedTLS Library Micron Confidential CAUTION: EXTERNAL EMAIL. Do not click links or open attachments unless you recognize the sender and were expecting this message. Hi Raunak, Mbed TLS today supports LMS stateful hash-based signature scheme. While supporting other PQC algorithms is in the Mbed TLS project roadmap, the team isn’t actively working on it. The focus for the team now is preparing for Mbed TLS 4.0. Feel free to ask any further technical questions in the Mbed TLS public mailing list - mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> (https://lists.trustedfirmware.org/mailman3/lists/mbed-tls.lists.trustedfirm…) Regards, Shebu Micron Confidential From: 'Raunak Gupta' via TFenquiries <enquiries(a)trustedfirmware.org> Sent: Tuesday, September 3, 2024 2:34 AM To: enquiries(a)trustedfirmware.org Subject: Inquiry About PQC Cryptos in embedTLS Library Micron Confidential Dear Trusted Firmware Team, I hope this message finds you well. My name is Raunak, and I am a Security Engineer at Micron Technology. I would like to inquire whether the embedTLS library has been updated to include Post-Quantum Cryptography (PQC) algorithms such as LMS, HSS, and XMSS. Additionally, is the embedTLS team actively working on integrating these PQC algorithms? Thank you for your assistance. Best regards, Raunak Micron Confidential To unsubscribe from this group and stop receiving emails from it, send an email to enquiries+unsubscribe(a)trustedfirmware.org<mailto:enquiries+unsubscribe@trustedfirmware.org>.

1 year, 7 months

1
0
0 0

Mbed TLS 3.6.1 and 2.28.9

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

1 year, 7 months

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

1 year, 7 months

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.

1 year, 7 months

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

1 year, 7 months

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.

1 year, 7 months

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.

1 year, 8 months

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

1 year, 8 months

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

1 year, 8 months

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.

1 year, 8 months

1
0
0 0