- mbed-tls - lists.trustedfirmware.org

best way to shut down network connection

by Gary Metalle

Hi What's the best way to shutdown a network connection for when say an embedded device is shutting down or going to reboot? I have the following code I call when I am going to kick off a reboot: LOG_DEBUG("Network Manager: Ethernet is going down%s", networkManager->rebootInProgress ? "..." : " for reconfiguration..."); netifapi_dhcp_release_and_stop(&networkManager->networkInterfaceContext); netifapi_netif_set_link_down(&networkManager->networkInterfaceContext); netifapi_netif_set_down(&networkManager->networkInterfaceContext); networkManager->ethernetLinkUp = false; if (networkManager->rebootInProgress) { netifapi_netif_remove(&networkManager->networkInterfaceContext); } The trouble is that the link seems to come back up again as soon as it goes down and my state machine starts doing stuff like kicking off a new DHCP request etc, right about the time the hardware reboots. I added in the call to netifapi_netif_remove() quite recently but it doesn't seem to make any difference. I could put some more code in my link status state machine for an impending reboot, but this seems more complicated than it probably needs to be, as I'm probably not doing something I should be. Gary Metalle Senior Embedded Software Engineer

2 years

1
0
0 0

PSA API support

by S Krishnan, Archanaa

Hello, What is the extent of PSA Crypto API 1.1 support available in mbedTLS today? From the road map, API v1.0 is supported. I also see that PBKDF, which is in PSA API v1.1, is in development. Regards, Archanaa

2 years

1
0
0 0

Is there a DTLS 1.3 roadmap?

by Achim Kraus

Hi List, last year I read in a comment https://github.com/Mbed-TLS/mbedtls/issues/5443#issuecomment-1017379238 that DTLS 1.3 is on the roadmap for the near future. Is it available? Are there any schedules? The Eclipse/wakaama project is looking for DTLS 1.3 (see https://github.com/eclipse/wakaama/issues/684), therefore I'm asking best regards Achim

2 years

3
2
0 0

Canceled event with note: MBed TLS Technical Forum @ Mon Apr 10, 2023 8:30am - 9:30am (MST) (mbed-tls@lists.trustedfirmware.org)

by don.harbin＠linaro.org

This event has been canceled with a note: "Bank Holiday - Cancelling " MBed TLS Technical Forum Monday Apr 10, 2023 ⋅ 8:30am – 9:30am Mountain Standard Time - Phoenix 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 nnac123(a)gmail.com 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. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years

1
0
0 0

[Mbed-tls-announce] New Mbed TLS releases : 3.4.0 and 2.28.3

by Paul Elliott via Mbed-tls-announce

Hi Mbed TLS users, We have released Mbed TLS versions 3.4.0 and 2.28.3 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/ARMmbed/mbedtls/releases/tag/mbedtls-3.4.0, https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.28.3). We recommend all users to consider whether they are impacted, and to upgrade appropriately. The Mbed TLS team IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

2 years

2
1
0 0

support of EC and hashing algorithms

by c.luetzenkirchen＠innolectric.ag

hello, I am currently evaluating if latest mbed-TLS release does support following algorithms: - ECDSA using secp521r1 curve - EDDSA using Edwards curves 448 or 448-Goldilocks - ECDH using mentioned curves - SHA512 - SHAKE256 For some of them like SHA512 I found information in the documentation. Others like EDDSA and SHAKE256 seem to be incomplete. Is my assumption correct that TLS 1.3 is therefore NOT ready to use yet? Best regards, Chris

2 years

1
0
0 0

Question about long-time support for 3.x branch

by Maher Azarkan

Hello everyone, We are currently using the mbedTLS version 2.16.12 in our firmware and we are planning an update to a newer branch. I would like to know, how long the different 3.x branches will be supported. Is there any fix roadmap, how long an mbedTLS branch must be supported and maintained after its first release? I could only find this information for the 2.28 branch (support until end of 2024). Thank you for any help you can offer. Best regards Maher Azarkan Hilscher Gesellschaft f?r Systemautomation mbH Rheinstra?e 15 / D-65795 Hattersheim / Germany Sitz der Gesellschaft / place of business: Hattersheim | Gesch?ftsf?hrer / managing director: Sebastian Hilscher, Hans-J?rgen Hilscher Handelsregister / commercial register: Frankfurt B 26873 | Ust. Idnr. / VAT No.: DE113852715 Registergericht / register court: Amtsgericht Frankfurt/Main Important Information: This e-mail message including its attachments contains confidential and legally protected information solely intended for the addressee. If you are not the intended addressee of this message, please contact the addresser immediately and delete this message including its attachments. The unauthorized dissemination, copying and change of this e-mail are strictly forbidden. The addresser shall not be liable for the content of such changed e-mails. Wichtiger Hinweis: Diese E-Mail einschlie?lich ihrer Anh?nge enth?lt vertrauliche und rechtlich gesch?tzte Informationen, die nur f?r den Adressaten bestimmt sind. Sollten Sie nicht der bezeichnete Adressat sein, so teilen Sie dies bitte dem Absender umgehend mit und l?schen Sie diese Nachricht und ihre Anh?nge. Die unbefugte Weitergabe, das Anfertigen von Kopien und jede Ver?nderung der E-Mail ist untersagt. Der Absender haftet nicht f?r Inhalte von ver?nderten E-Mails.

2 years, 1 month

3
2
0 0

Porting from OpenSSL to MbedTLS

by matteo.cogi＠alice.it

Dear all, I need to migrate from OpenSSL to MbedTLS. I have to implement a SCEP client in my embedded environment composed by FreeRTOS as OS, mbedTLS as security layer and LwIP as network stack. The best candidate for the SCEP client role is the sscep library. It works very well under Ubuntu, but now I need to use it in my embedded environment, so I have to adapt sscep for MbedTLS. I would like to know if there is some porting/migration guide from OpenSSL to MbedTLS. Any kind of suggestion or support will be appreciated. Thanks in advance. Regards, Matteo

2 years, 1 month

3
2
0 0

Reminder: MBed TLS Tech Forum - Asia/Europe

by Don Harbin

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech forum is next Monday at 10:00am PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 1 month

1
0
0 0

security issue in mbedtls 3.30

by Avi Epstein

security issue in mbedtls 3.30 in the release notes: "An adversary with access to precise enough information about memory accesses (typically, an untrusted operating system attacking a secure enclave) could recover an RSA private key after observing the victim performing a single private-key operation if the window size used for the exponentiation was 3 or smaller. Found and reported by Zili KOU, Wenjian HE, Sharad Sinha, and Wei ZHANG. See "Cache Side-channel Attacks and Defenses of the Sliding Window Algorithm in TEEs" - Design, Automation and Test in Europe 2023." was this issue solved in this version?

2 years, 1 month

2
1
0 0

ECDSA read_signature returns "invalid signature" status

by Tilen Majerle

Hello, I have 3rd party custom ECC library, that can do ECDSA verification and uses secp256r1 compressed public key (33bytes) to do so - all works fine. Now I want to migrate to mbedTLS, to also benefit of other crypto schemes, hence use of mbedtls ECDSA was a natural way to go. Here I need (as I understand) PEM parser or optionally public key in uncompressed format (0x04 | X | Y). Problem is that loading of the key seems to work (func returns 0), but verification fails with -20450, indicating (if I well understood) invalid signature. Test data. PRIVATE KEY: -----BEGIN PRIVATE KEY----- MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgKNqyWso/lMuTlTE6 ll47Jboqq/Iz7OYDrr7TuXN+s2ChRANCAARNgfaUcxLoWWG01ekJFiqB8ujMgnHz P320ZgiZErH6zKjlB9EovIHrchj0240+EIpFios+2uM609FgRvu3+NrT -----END PRIVATE KEY----- PUBLIC KEY: -----BEGIN PUBLIC KEY----- MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADTYH2lHMS6FlhtNXpCRYqgfLozIJx 8z99tGYImRKx+sw= -----END PUBLIC KEY----- PUBLIC KEY UNCOMPRESSED SEC1: 0x4,0x4d,0x81,0xf6,0x94,0x73,0x12,0xe8,0x59,0x61,0xb4,0xd5,0xe9,0x9,0x16,0x2a,0x81,0xf2,0xe8,0xcc,0x82,0x71,0xf3,0x3f,0x7d,0xb4,0x66,0x8,0x99,0x12,0xb1,0xfa,0xcc,0xa8,0xe5,0x7,0xd1,0x28,0xbc,0x81,0xeb,0x72,0x18,0xf4,0xdb,0x8d,0x3e,0x10,0x8a,0x45,0x8a,0x8b,0x3e,0xda,0xe3,0x3a,0xd3,0xd1,0x60,0x46,0xfb,0xb7,0xf8,0xda,0xd3 PUBLIC KEY COMPRESSED SEC1: 0x3,0x4d,0x81,0xf6,0x94,0x73,0x12,0xe8,0x59,0x61,0xb4,0xd5,0xe9,0x9,0x16,0x2a,0x81,0xf2,0xe8,0xcc,0x82,0x71,0xf3,0x3f,0x7d,0xb4,0x66,0x8,0x99,0x12,0xb1,0xfa,0xcc INPUT STRING in TEXT format: "This is my input data" (remove quotes) INPUT STRING in HEX format: 0x54,0x68,0x69,0x73,0x20,0x69,0x73,0x20,0x6d,0x79,0x20,0x69,0x6e,0x70,0x75,0x74,0x20,0x64,0x61,0x74,0x61 SHA256 of INPUT STRING: 0xa7,0x3f,0x26,0xf4,0xa1,0xe4,0x61,0x61,0x0,0x1a,0x29,0xdf,0xd2,0xaf,0x7d,0xa,0x25,0x91,0xbb,0xcc,0x1f,0xbc,0xfb,0xdb,0x43,0xdb,0x57,0xf9,0x8d,0x94,0xeb,0x81 (x-checked here: https://emn178.github.io/online-tools/sha256.html) SIGNATURE of HASH signed with PRIVATE KEY: 0x80,0xe6,0xf5,0x97,0x6a,0x66,0xa2,0xe2,0x9a,0xd7,0x7f,0x9a,0x9b,0x3e,0x2b,0xde,0x1f,0x7c,0x3,0xb3,0x1,0xb8,0x6f,0xd8,0xf6,0xf,0x27,0x38,0x63,0x3,0x54,0x74,0x76,0x6d,0x1b,0x97,0xf0,0xbc,0xc5,0xd2,0x4b,0xae,0xf0,0x34,0xab,0x86,0xbd,0x55,0x0,0x8a,0x4c,0x9f,0x4e,0xa5,0x53,0x89,0xe8,0x0,0xb9,0x83,0x24,0x87,0x98,0x1 My custom library code looks like - this one works as expected: if (ecdsa_verify(public_key_compressed_33_bytes_array, hash_of_input_string, signature_signed_with_private_key)) { printf("Custom ECDSA lib verification is OK\r\n"); } My mbedTLS code looks like: ``` /* mbedTLS */ printf("mbedTLS way start\r\n"); mbedtls_ecdsa_init(&ctx); mbedtls_ecp_group_load(&ctx.private_grp, MBEDTLS_ECP_DP_SECP256R1); res = mbedtls_ecp_point_read_binary(&ctx.private_grp, &ctx.private_Q, ecc_public_key_uncompressed_bin, sizeof(ecc_public_key_uncompressed_bin)); if (res != 0) { printf("ECP point read binary failed: %d\r\n", res); } res = mbedtls_ecdsa_read_signature(&ctx, data_raw_hash_digest, sizeof(data_raw_hash_digest), signature, sizeof(signature)); if (res == 0) { printf("mbedTLS Verification is OK...\r\n"); } else { printf("mbedTLS Verification failed...: %d\r\n", res); } printf("mbedTLS way end\r\n"); ``` and it always fails with error code -20450. while loading keys function goes through well. Am I wrongly loading the keys?

2 years, 1 month

2
2
0 0

PKCS#7 signedAttributes and embedded cert chain

by Joakim Sindholt

Hi, I recently had to do some PKCS#7 signature validation and was disappointed to find that it didn't just work. After digging through RFCs to figure out the myriad of things I'd done wrong I was also left with a lack of 3 features in mbedtls: 1. The full certificate chain was not being loaded and explicitly not supported. I believe this is in error since the certificate was never actually used anywhere, meaning it basically errored out for no reason. Since this certificate chain also contains the key used to validate the signature in my case that presented a pretty fundamental problem. 2. signedAttributes were not supported at all. 3. All the fields in mbedtls_pkcs7 and its associated structures are marked as MBEDTLS_PRIVATE. I need to inspect both the certificates and the signedAttributes and would rather not have to parse the entire DER myself. I have attached patches implementing the first two. I believe I've done so without altering the behavior of the calls although I'm a bit unsure as to why mbedtls_x509_crt_verify doesn't take a const mbedtls_x509_crt. The third issue is a matter of policy and I don't know what your opinion on it is. For the moment I can at least get away with poking at the internal fields. I have tested it on several signatures, one of which I have included here and I apologize in advance for the absolute spew but I thought it better than attaching even more files. The data: 3059301306072A8648CE3D020106082A8648CE3D030107034200041B58AEE5B7C868AE0EED554133774B7C16802062EC2EB5A1A053318A9ED7DB943CE1F877671DADCFEB4D3171ACC2714ECBC0C0BCADE0569DF7CD0031623AF1BBDE72D8FFF60EC6D04B0D6C93658FC40F4AF2E22E1F68BF1A500FE00A94B804B7CA1DD7AF825C000FCF77A0ABB6918D2DF55C7A3CBC90BE14C59D8EE62A02B988DF7F32117770012AE362C03FB3AA3918AB9D10BE78442EFA7FCBA3CB02D6E196CE4137C6C3F280D963A5CD050EAC8871B3EB2C4500916FB3E39840D8EB198D58F49A434B2736385075BF9397405360B8694D0AD1E5DA8291F9EA47743F803F4A409EA72C2DF94F43DB60A0EAB8A8BD409C4D684200778B23D2A8126827995C3A80CAACA4AB7077266CED79BF91725330C9FCE3B8F1F5316C08C17B9994CF0ECB26D87A5C1F8FEB1FA737F78794895F6C5153B575EF8E95A8D433FD9486AA6C2B46ED6633D2BE0938202B99BEC21895018FB6FC59BAD662815A2C65200B8B1BAA4B69A8C89204B1EA70094026E9F710E599E14941476C8CD2E2879CF58E850DC732A506885F646BB9BE96B7A65355A6A9B907956E6DF65336504300CF062BA9DE50 It's SHA2-256 hash is: C76DE7AF191C16E01405CE8FE89136EB60AC035B3DDE34ACF65220AC7C3CA619 If you decode the signature DER you'll see a matching id-messageDigest in the signedAttributes towards the very bottom. The signature in DER format: 3082089B06092A864886F70D010702A082088C30820888020101310D300B0609608648016503040201300B06092A864886F70D010701A08206D9308203E330820388A00302010202084C304149519D5436300A06082A8648CE3D040302307A312E302C06035504030C254170706C65204170706C69636174696F6E20496E746567726174696F6E204341202D20473331263024060355040B0C1D4170706C652043657274696669636174696F6E20417574686F7269747931133011060355040A0C0A4170706C6520496E632E310B3009060355040613025553301E170D3139303531383031333235375A170D3234303531363031333235375A305F3125302306035504030C1C6563632D736D702D62726F6B65722D7369676E5F5543342D50524F4431143012060355040B0C0B694F532053797374656D7331133011060355040A0C0A4170706C6520496E632E310B30090603550406130255533059301306072A8648CE3D020106082A8648CE3D03010703420004C21577EDEBD6C7B2218F68DD7090A1218DC7B0BD6F2C283D846095D94AF4A5411B83420ED811F3407E83331F1C54C3F7EB3220D6BAD5D4EFF49289893E7C0F13A38202113082020D300C0603551D130101FF04023000301F0603551D2304183016801423F249C44F93E4EF27E6C4F6286C3FA2BBFD2E4B304506082B0601 050507010104393037303506082B060105050730018629687474703A2F2F6F6373702E6170706C652E636F6D2F6F63737030342D6170706C65616963613330323082011D0603551D2004820114308201103082010C06092A864886F7636405013081FE3081C306082B060105050702023081B60C81B352656C69616E6365206F6E207468697320636572746966696361746520627920616E7920706172747920617373756D657320616363657074616E6365206F6620746865207468656E206170706C696361626C65207374616E64617264207465726D7320616E6420636F6E646974696F6E73206F66207573652C20636572746966696361746520706F6C69637920616E642063657274696669636174696F6E2070726163746963652073746174656D656E74732E303606082B06010505070201162A687474703A2F2F7777772E6170706C652E636F6D2F6365727469666963617465617574686F726974792F30340603551D1F042D302B3029A027A0258623687474703A2F2F63726C2E6170706C652E636F6D2F6170706C6561696361332E63726C301D0603551D0E041604149457DB6FD57481868989762F7E578507E79B5824300E0603551D0F0101FF040403020780300F06092A864886F76364061D04020500300A06082A8648CE3D0403020349003046022100BE09571FE71E1E7 35B55E5AFACB4C72FEB445F30185222C7251002B61EBD6F55022100D18B350A5DD6DD6EB1746035B11EB2CE87CFA3E6AF6CBD8380890DC82CDDAA63308202EE30820275A0030201020208496D2FBF3A98DA97300A06082A8648CE3D0403023067311B301906035504030C124170706C6520526F6F74204341202D20473331263024060355040B0C1D4170706C652043657274696669636174696F6E20417574686F7269747931133011060355040A0C0A4170706C6520496E632E310B3009060355040613025553301E170D3134303530363233343633305A170D3239303530363233343633305A307A312E302C06035504030C254170706C65204170706C69636174696F6E20496E746567726174696F6E204341202D20473331263024060355040B0C1D4170706C652043657274696669636174696F6E20417574686F7269747931133011060355040A0C0A4170706C6520496E632E310B30090603550406130255533059301306072A8648CE3D020106082A8648CE3D03010703420004F017118419D76485D51A5E25810776E880A2EFDE7BAE4DE08DFC4B93E13356D5665B35AE22D097760D224E7BBA08FD7617CE88CB76BB6670BEC8E82984FF5445A381F73081F4304606082B06010505070101043A3038303606082B06010505073001862A687474703A2F2F6F6373702E6170706C 652E636F6D2F6F63737030342D6170706C65726F6F7463616733301D0603551D0E0416041423F249C44F93E4EF27E6C4F6286C3FA2BBFD2E4B300F0603551D130101FF040530030101FF301F0603551D23041830168014BBB0DEA15833889AA48A99DEBEBDEBAFDACB24AB30370603551D1F0430302E302CA02AA0288626687474703A2F2F63726C2E6170706C652E636F6D2F6170706C65726F6F74636167332E63726C300E0603551D0F0101FF0404030201063010060A2A864886F7636406020E04020500300A06082A8648CE3D040302036700306402303ACF7283511699B186FB35C356CA62BFF417EDD90F754DA28EBEF19C815E42B789F898F79B599F98D5410D8F9DE9C2FE0230322DD54421B0A305776C5DF3383B9067FD177C2C216D964FC6726982126F54F87A7D1B99CB9B0989216106990F09921D3182018830820184020101308186307A312E302C06035504030C254170706C65204170706C69636174696F6E20496E746567726174696F6E204341202D20473331263024060355040B0C1D4170706C652043657274696669636174696F6E20417574686F7269747931133011060355040A0C0A4170706C6520496E632E310B300906035504061302555302084C304149519D5436300B0609608648016503040201A08193301806092A864886F70D010903310B06092A864 886F70D010701301C06092A864886F70D010905310F170D3233303230393231333032345A302806092A864886F70D010934311B3019300B0609608648016503040201A10A06082A8648CE3D040302302F06092A864886F70D01090431220420C76DE7AF191C16E01405CE8FE89136EB60AC035B3DDE34ACF65220AC7C3CA619300A06082A8648CE3D04030204473045022100EE9B221CD9B5EEB1C6AF4160128D099C9414440A96C855A789846599E3BDE442022005AE51DC947E0B2AA6593E8FDB9F888782C71E5BB1CB6BF3C32B79C448C6A75D Joakim

2 years, 2 months

3
5
0 0

Reminder: MBed TLS Tech Forum - Asia

by Don Harbin

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech forum is next *Monday, Feb 27th at 10:00am UK time*. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. As usual, if anyone has any topics, please let Dave Rodgman, cc'd, know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 2 months

1
0
0 0

Could anyone please handle these PR?

by Elsa zz

Hi, I'm new here. I found some issues and submitted the pull requests. Could anyone please handle these PR? - https://github.com/Mbed-TLS/mbedtls/pull/6511 - https://github.com/Mbed-TLS/mbedtls/pull/6224 Thanks!

2 years, 2 months

2
1
0 0

Where is the AES 128 GCM key expansion/generate round key performed?

by Mbed TLS

Hi, I'm using AES 128 GCM with TLS 1.2 and trying to understand the AES key expansion code for decrypting received SSL records. I'm not an expert on AES but as I understand it, we use the IV (4 byte salt + 8 byte explicit nonce in the received message), pad to 16 bytes, increment and use this as input to the AES key expansion for the first block of ciphertext. This produces a round key per AES round (10 rounds for AES 128). We then increment our IV as input to the key expansion and generate the rounding keys for the next block. I noticed aesni_setkey_enc_128 in aesni.c contains the Intel AES-NI instruction AESKEYGENASSIST which helps with key expansion. However, what's confusing me is when I add a breakpoint in GDB, this function is only called once, via mbedtls_ctr_drbg_seed in ctr_drbg.c. I thought we need to do the key expansion on every block, to generate the round keys? I kept looking at the code and I noticed mbedtls_aesni_crypt_ecb, which contains the Intel AES-NI instructions for performing decryption. This loads the round key via ctx->buf + ctx->rk_offset but I do not see any code updating this round key per block. Could someone please explain where the round keys are generated for each round, per block? Thanks,

2 years, 2 months

4
6
0 0

Should TLS be blocking all FreeRTOS tasks which use LWIP, during its RSA/EC phase, regardless of priorities?

by Peter

Hi All, I have a couple of tasks which use LWIP and which get suspended for a few seconds during TLS RSA/EC crypto. One (a primitive http server) uses Netconn and the other (a serial to TCP data copy process) uses sockets. I also have a number of tasks which don't do any networking and which run as they should, throughout. Experimentation of what priority these need is difficult but it looks like it needs to be at/above the tasks which invoke TLS. If their priority is 0 then TLS hangs them up as well. After much experimentation with RTOS priorities, this is what I found, and I wonder if it is right: TCP/IP applications (whether using the LWIP Netconn API or the LWIP socket API) should run at a priority equal to or lower than that of LWIP itself which [in this project] is osPriorityHigh (40). TCP/IP applications can be run with a priority all the way down to tskIDLE_PRIORITY (0). The exception is if TLS is in use. TLS does not yield to the RTOS; you get a solid CPU time lump of ~3 secs (STM 32F417, hardware AES only). TLS starts in the priority of the task which invokes it, but subsequent TLS-driven TCP/IP operations run at the priority of LWIP. So when TLS is doing the session setup crypto, tasks of a priority lower than LWIP get suspended. If this gap is an issue, the priority of the relevant tasks should be equal to LWIP's. Furthermore, due to the structure of LWIP, the priority of a task using it should not be higher than LWIP (24) since it might cause blocking on socket (or netconn) writes. Does this make sense? It looks like LWIP blocks all netconn and socket ops when TLS is using it. Is that possible? I am running with #define LWIP_TCPIP_CORE_LOCKING 0 #define LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT 1 #define SYS_LIGHTWEIGHT_PROT 1 as this was found to have much better granularity for task switching. With LWIP_TCPIP_CORE_LOCKING=1 you end up with a crude mutex across the entire API call, which is fine in a single RTOS task. Thank you in advance for any pointers. Peter

2 years, 2 months

2
2
0 0

Generating self signed certificate

by Prithvi Pai

Hi Team, I have a requirement to generate self signed certificate programmatically. I have raw EDCSA key pairs generated via OP-TEE APIs. I m trying to generate self signed certificate. I tried the example as shown in programs/x509/cert_write.c. This doesn't work for me as I have raw key pairs where as this expects the key pairs to be in either pem/der format. I tried the following code but it throws error "0xffffdd00" when I call mbedtls_x509write_crt_der Code to set the raw key pairs: mbedtls_ecdh_context issuer_ctx; mbedtls_ecdh_init(&issuer_ctx); ret = mbedtls_ecdh_setup(&issuer_ctx, MBEDTLS_ECP_DP_SECP384R1); if (ret != 0) { goto exit; } res = TA_ECSetPublicKey(&issuer_ctx, public_keyX, public_key_Y, 48); if (res != TEE_SUCCESS) { goto exit; } res = TA_ECSetPrivateKey(&issuer_ctx, private_key, 48); if (res != TEE_SUCCESS) { goto exit; } Am I doing something wrong ? Please help It would be very helpful if some working example of generating certificate programmatically is shared for my reference Thanks, Prithvi

2 years, 2 months

1
1
0 0

Can the same mbedtls_ssl_context be used simultaneously for send and receive from different tasks?

by pascal.haefliger＠schweizer-electronic.com

Hello, In our project we use mbedTLS together with freeRTOS. mbedTLS requires an mbedtls_ssl_context (let's say `ssl_context`) for the send (`mbedtls_ssl_write(...)`) and receive (`mbedtls_ssl_read(...)`) functions. In our project we have a freeRTOS task `A` to send data with mbedTLS and a freeRTOS task `B`to receive data with mbedTLS over the same session/interface. Both tasks use the same `ssl_context` instance. Potentially sending and receiving can happen at the same time. Is it safe to use the same `ssl_context` instance from both taks? Or should only one task access the `ssl_context`? At the moment we are using `mbedtls_ssl_read(...)` in blocking mode and hence the `ssl_context` cannot be protected against multiple access with a mutex because then the sending task cannot obtain the mutex as long as the receiving task is the blocked receiving state (holding the mutext). Thank you for your help. Best regards, Pascal

2 years, 2 months

1
0
0 0

Intent to remove DES in Mbed TLS 4.0

by Gilles Peskine

Hello, We intend to remove DES (including Triple-DES) in the next major version of Mbed TLS, i.e. Mbed TLS 4.0. We do not yet have a release date, but at the moment it seems likely that there will be a new major version in 2024. As usual, the Mbed TLS 3.x series will keep the current support for DES, and we intend to maintain the last 3.x minor release as a long-term support branch for 3 years. Rationale: Most security standards deprecate DES if they do not forbid it already. Tooling is widely available to switch to AES or other cipher. In particular, NIST will forbid Triple-DES except to decrypt legacy data after 31 December 2023 (following SP 800-131A <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf>). We would like to remove the last 64-bit block cipher from Mbed TLS to simplify some parts of the code and reduce the maintenance burden. If you wish for Mbed TLS to keep supporting DES longer, please let us know what your business case is, either by replying to this email or on the GitHub issue: https://github.com/Mbed-TLS/mbedtls/issues/7024 Best regards, -- Gilles Peskine Mbed TLS developer

2 years, 2 months

2
1
0 0

Builtin keys and Opaque driver wrappers.

by Rehan Malak

Dear MbedTLS dev, I am writing an opaque driver (equivalent of PSA_CRYPTO_TEST_DRIVER_LOCATION/PSA_KEY_PERSISTENCE_READ_ONLY in the test suite) with the PSA API compiled with MBEDTLS_PSA_CRYPTO_BUILTIN_KEYS. But I am not sure if I have to use "psa_import_key" before "psa_driver_wrapper_sign_message" or if I have to "read/generate" the builtin key on the fly, at each psa_driver_wrapper_* operation ? Would it be possible to add this example in the test suite ? Or explain how builtin key + opaque driver is supposed to be used with, for example, "psa_driver_wrapper_sign_message" ? I put more details below. Thank you in advance, Best regards, Rehan ############################################################################# I would like to write an example doing : I) psa_sign_message (ECDSA SECP256R1 SHA-256) II) psa_export_public_key III) psa_verify_message (with the public key from II) I am following the examples provided by the test suite, especially : 1) sign_message transparent driver: calculate in driver ECDSA SECP256R1 SHA-256 using the API : - psa_import_key - psa_sign_message with the attributes : - key_type = PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1) 2) PSA opaque driver builtin pubkey export: secp256r1 using the API : - psa_export_public_key with the attributes : - key_id = MBEDTLS_PSA_KEY_ID_BUILTIN_MIN + 1 - key_type = PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1) and the driver code : - platform_builtin_keys.c : mbedtls_psa_platform_get_builtin_key() (PSA_KEY_PERSISTENCE_READ_ONLY, PSA_CRYPTO_TEST_DRIVER_LOCATION) - test_driver_key_management.c : mbedtls_test_opaque_export_public_key() 3) verify_message transparent driver: calculate in driver ECDSA SECP256R1 SHA-256 using the API : - psa_import_key - psa_verify_message with the attributes : - key_type = PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1) It seems to me that II)=2) and 3) should be pretty similar to III) because I assume that neither transparent vs opaque, nor PSA_KEY_TYPE_ECC_KEY_PAIR vs PSA_KEY_TYPE_ECC_PUBLIC_KEY_BASE, is gonna change much here. But the signature I) is less clear... Has the built-in key feature been thought such that the read-only key is read each time we call a different PSA API function ? Long story short, an "opaque driver + builtin keys" equivalent of the "sign_message transparent driver: calculate in driver ECDSA SECP256R1 SHA-256" example in the test-suite would be really helpful :)

2 years, 3 months

2
1
0 0

PSA crypto support for RH850 Microcontroller

by Tambe, Ujjwal (TCS)

Hello, Is it possible to use PSA crypto APIs for SHA256 and RSA signature verification for RH850F1KMS1 microcontroller from renesas which has G3KH cpu core. Let me know your thoughts. Thank you in advance. Regards, Ujjwal

2 years, 3 months

1
0
0 0

Mbed TLS support for Renesas RH850 microcontroller

by Tambe, Ujjwal (TCS)

Hello, I am writing this mail in order to get support. I am using RH850-F1KMS1 microcontroller from Renesas, and I need to integrate mbed to perform SHA256 and RSA-1024 digital signature verification. The controller is bare metal and does not have any OS like freeRTOS. Just want to understand how to integrate mbed code in our project. Thank you in advance for the help. Regards, Ujjwal

2 years, 3 months

1
0
0 0

Reminder: MBed TLS Technical 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:30 PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Dave, Please keep in mind that next Monday is a Federal Holiday in the US, so this may impact attendance. Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 3 months

1
0
0 0

[Mbed-tls-announce] Coding style change in Mbed TLS

by Gilles Peskine via Mbed-tls-announce

Hello, You are concerned if: you contribute to Mbed TLS, or you maintain local patches to Mbed TLS. You are not concerned if: you just use Mbed TLS. We are going to change the C coding style in Mbed TLS. The new style is mostly what you'd find in The C Programming Language, 2nd edition, by Brian Kernighan and Dennis Ritchie (K&R2). The main changes compared to the current style are: * Spaces outside parentheses, not inside. No space in f(x). * Opening braces on the same line as if(), for(), etc., but on a separate line for functions. Indentation remains 4 spaces. The recommended maximum line length remains 80 columns. There are a few deviations from K&R2, documentation will be available shortly. The new code style will be enforced by the CI testing. This means that style that's rejected by the tool will not be merged, full stop. This also means that sometimes we'll have code that looks a bit less good to humans because the tool insists on it. We're doing this to avoid wasting reviewers' and contributors' time with style violations in code review. The tool we're using is uncrustify<https://github.com/uncrustify/uncrustify>. You can see how your code will look like by installing uncrustify 0.75.1 and running scripts/code_style.py from mbedtls-3.3.0 or mbedtls-2.28.2. There are previews of the rewritten branches at https://github.com/Mbed-TLS/mbedtls/tree/features/new-code-style/development and https://github.com/Mbed-TLS/mbedtls/tree/features/new-code-style/mbedtls-2.… (updated every few days until the real branches are rewritten). If you're now starting work on a new feature or bugfix, it will probably be easier to start from those branches, and do an easy rebase once they become official. If you've been working on a branch, we will provide a script to rebase the branch and rewrite it to the new style commit by commit. You'll need to have uncrustify 0.75.1. Concretely, when we change the code style: * If you've started to work on a branch but review has not started yet, we'll ask you to adapt your branch to the new code style. * If your work is under review, you'll need to adapt your branch to the new code style before it can be merged. Rebasing a branch is disruptive for reviews, so please synchronize with the reviewers to decide on a good time. We plan to do the switch during the first week of January 2023. Best regards, -- Gilles Peskine Mbed TLS developer IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

2 years, 3 months

2
2
0 0

[Mbed-TLS/mbedtls] MS-MPPE-RECV key is not getting correct value in MBEDTLS

by Ajay Mishra

Hi All, I raised the issue below in the MBED-TLS github, as per suggestion from the moderator asking it in the mailing-list. Below are the details. https://github.com/Mbed-TLS/mbedtls/issues/6864 I am running Mbed TLS as a core security library(2.24.0), on an embedded platform. I am using the FreeRADIUS server for AAA authentication. I am able to get the PMK values correctly at the supplicant side, however while decrypting the MPPE key at the gateway side I see that the values are incorrect specially in the API(radius_client_sec_prot_ms_mppe_recv_key_pmk_decrypt) Below are my setup details: FreeRADIUS server setup on Ubuntu(3.2.1) openssl :1.1.1f Ubuntu version : 20.04.04LTS System information Client side setup Platform : Micro controller based platform OS : FreeRTOS Compiler gcc-arm-none-eabi-8-2019-q3-update Sample example MPPE KEY in clear at RADIUS Server Fri Dec 30 23:50:13 2022 : Debug: (209) MS-MPPE-Recv-Key = 0x2f6c3e7e748eb49a598c208af3ef520454f5aa6873bc72f7f32be1053914a566 Fri Dec 30 23:50:13 2022 : Debug: (209) MS-MPPE-Send-Key = 0xa04539819a272e94782af1818b05878bb0e420d08a51accd6c3cb75baaecbd75 PMK Key values at Supplicant(which is same as MPPE-RECV-KEY) PMK Key values at Supplicant(which is same as MPPE-RECV-KEY) 2022-12-30 23:50:07.313 #1 0000000000000000 <log> 0:28:21.215 [debug] [ tlsp] {Wi-SUN Ev}: >>>> PRINT THE KEY PMK >>>> 2022-12-30 23:50:07.313 #1 0000000000000000 <log> 0:28:21.224 [debug] [ tlsp] {Wi-SUN Ev}: EAP-TLS key material 2f:6c:3e:7e:74:8e:b4:9a:59:8c:20:8a:f3:ef:52:04:54:f5:aa:68:73:bc:72:f7:f3:2b:e1:05:39:14:a5:66 which is same as the value that we see at the RADIUS Server. Decrypted key Value at Authenticator(using the API radius_client_sec_prot_ms_mppe_recv_key_pmk_decrypt) 2022-12-30 23:51:34.763 #1 0000000000000000 <log> 3:09:17.919 [debug] [ hmac] {Wi-SUN Ev}: hmac_md key a9:69:02:e9:3a:1d:cd:05:31:b3:77:cd:d6:d7:c2:c7:2d:52:4b:0a:5b:b1:aa:81:20:67:dd:b8:1c:04:ef:63 Mbed TLS version (number or commit id): 2.24.0 Operating system and version: Configuration (if not default, please attach mbedtls_config.h): Compiler and options (if you used a pre-built binary, please indicate how you obtained it): Additional environment information: Expected behavior The key should be decrypted with the correct value. Actual behavior The key is not getting the correct value. Steps to reproduce Additional information Kindly let me know what is missing here ? Thanks in advance. With regards, Ajay. Brentwood, UK.

2 years, 3 months

1
1
0 0

Simultaneous accepts

by David Higton

With mbedTLS set up as a streaming server (e.g. https), can it deal with two attempts to connect that arrive in quick succession, so two handshakes are occurring simultaneously? David

2 years, 3 months

1
0
0 0

Non-Blocking HTTPS read/write using MbedTLS

by Sritam Paltasingh

I have a working Client code in which I use MbedTLS functions to send HTTPS GET request to my server. For sending data to the server, I use mbedtls_ssl_write(). But this call is blocking. My goal is to make this function call (mbedtls_ssl_write()) non-blocking. What is the correct way to do it ? I read the documentation and concluded that: 1. I have to set the bio callbacks using the mbedtls_ssl_set_bio() function where I have to pass the callback functions as parameters in this function call. 2. I have to set the SSL context as non-blocking using the mbedtls_net_set_nonblock() function call 3. I have used the default bio callbacks, named mbedtls_net_send and mbedtls_net_recv, which are defined in net_sockets.c My question is: After setting the default bio callbacks (mbedtls_net_send and mbedtls_net_recv) and setting the SSL context as non-blocking (mbedtls_net_set_nonblock) which function should I use for non-blocking write/read. Will it be mbedtls_ssl_write() and mbedtls_ssl_read() ? And will the call back functions (which are set using mbedtls_ssl_set_bio) be called when read/write completes? Please help me with advice on how to implement non-blocking write/read using MbedTLS functions. Thanks and Regards, Sritam Paltasingh.

2 years, 3 months

1
0
0 0

PSA Drivers and "add_entropy" interface.

by Ruchika Gupta

Hi, PSA driver interface specification talks about "add_entropy" entry point. Snippet pasted below. https://github.com/Mbed-TLS/mbedtls/blob/development/docs/proposed/psa-driv… *A driver can declare an entropy source by providing a "get_entropy" entry point. This entry point has the following prototype for a driver with the prefix "acme":* *psa_status_t acme_get_entropy(uint32_t flags, size_t *estimate_bits, uint8_t *output, size_t output_size);* However, in the current implementation of MbedTLS 3.x I don't see this implemented . With the psa_crypto-init() what I observe is that if the platform enables MBEDTLS_ENTROPY_HARDWARE_ALT then using " mbedtls_hardware_poll(), the entropy source can be provided. Can you please confirm if this observation is correct and also let us know if the <driver>_get_entropy() is planned to be implemented in near future ? Regards, Ruchika

2 years, 3 months

2
2
0 0

Canceled event: MBed TLS Technical Forum - Asia @ Mon Jan 2, 2023 3am - 3:50am (MST) (mbed-tls@lists.trustedfirmware.org)

by don.harbin＠linaro.org

This event has been canceled. MBed TLS Technical Forum - Asia Monday Jan 2, 2023 ⋅ 3am – 3:50am Mountain Standard Time - Phoenix Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt Guests Don Harbin - creator nnac123(a)gmail.com santosdanillo(a)gmail.com schoenle.thomas(a)googlemail.com kris.kwiatkowski(a)pqshield.com 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. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 4 months

1
0
0 0

Regarding implementation of MBED CRYPTO libraries without entropy source on baremetal

by PRASHANT TRIPATHI

Dear sir/madam I have following queries regarding implementation of MBED CRYPTO Libraries : 1) How crypto libraries files could be used on baremetal with no entropy source(cross compilation )? 2) How asymmetric cryptographic operations like RSA , RNG , EC ,DSA etc , could be implemented on baremetal without entropy , seed provisions ? 3) If i want to use some custom PRNG and entropy , then how the respective contexts structures could be filled ? Thanks & Regards, *Prashant Tripathi*

2 years, 4 months

2
3
0 0

[Mbed-tls-announce] Mbed TLS 3.3.0 and Mbed TLS 2.28.2

by Dave Rodgman via Mbed-tls-announce

Hi Mbed TLS users, We are pleased to announce the release of Mbed TLS versions 3.3.0 and 2.28.2. 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/ARMmbed/mbedtls/releases/tag/mbedtls-3.3.0 and https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.28.2 ). We recommend all users to consider whether they are impacted, and to upgrade appropriately. The releases are available from https://github.com/Mbed-TLS/mbedtls/releases Dave Rodgman IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

2 years, 4 months

1
0
0 0

Reminder: MBed TLS Technical 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:30 PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 4 months

1
0
0 0

About setting arbitrary RDN while generating a CSR with mbedtls

by Aditya Patwardhan

I am using mbedtls_x509write_csr_set_subject_name API from mbedtls to set the subject name. I wanted to set the arbitrary old value in my certificate for e.g. ffeBgt9jDHhBwPDANgtT7R/1.3.6.1.4.1.37244.2.1=FFF2/1.3.6.1.4.1.37244.2.2=8001 In this case ffeBgt9jDHhBwPDANgtT7R is the CN And 1.3.6.1.4.1.37244.2.1 is an arbitrary OID which has a value of FFF2 similar to the second arbitrary OID. I am able to do this through openssl commands, but while doing it through mbedtls, when I pass it as a string then mbedtls considers the whole string as CN which Is not my intention. Please fine the asn1 parsing of the CSR as below CSR generated through mbedtls: 18:d=5 hl=2 l= 3 prim: OBJECT :commonName 23:d=5 hl=2 l= 76 prim: UTF8STRING :ffeBgt9jDHhBwPDANgtT7R/1.3.7.1.4.1.37466.2.1=FFF2+1.3.7.1.4.1.37466.2.2=8001 101:d=3 hl=2 l= 11 cons: SET 103:d=4 hl=2 l= 9 cons: SEQUENCE Target CSR ( done thorough openssl): 14:d=4 hl=2 l= 29 cons: SEQUENCE 16:d=5 hl=2 l= 3 prim: OBJECT :commonName 21:d=5 hl=2 l= 22 prim: UTF8STRING :ffeBgt9jDHhBwPDANgtT7R 45:d=3 hl=2 l= 20 cons: SET 47:d=4 hl=2 l= 18 cons: SEQUENCE 49:d=5 hl=2 l= 10 prim: OBJECT :1.3.7.1.4.1.37466.2.1 61:d=5 hl=2 l= 4 prim: UTF8STRING :FFF2 67:d=3 hl=2 l= 20 cons: SET 69:d=4 hl=2 l= 18 cons: SEQUENCE 71:d=5 hl=2 l= 10 prim: OBJECT :1.3.7.1.4.1.37466.2.2 83:d=5 hl=2 l= 4 prim: UTF8STRING :8001 89:d=2 hl=2 l= 89 cons: SEQUENCE 91:d=3 hl=2 l= 19 cons: SEQUENCE 93:d=4 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 102:d=4 hl=2 l= 8 prim: OBJECT :prime256v1 Am I missing something here? Do I need to provide the CN in a different way to get the intended result? I found an open issue https://github.com/Mbed-TLS/mbedtls/issues/4886, could it be related to this? Any help would be appreciated. Thanks and Regards, Aditya

2 years, 4 months

2
1
0 0

MbedTLS crashes with some websites in mbedtls_mpi_free()

by Peter

Hi All, Some websites crash MbedTLS, in void mbedtls_ecp_point_free( mbedtls_ecp_point *pt ) { if( pt == NULL ) return; mbedtls_mpi_free( &( pt->X ) ); mbedtls_mpi_free( &( pt->Y ) ); mbedtls_mpi_free( &( pt->Z ) ); } It crashes in the last function call of the three above. Thread #1 [main] 1 [core: 0] (Suspended : Signal : SIGTRAP:Trace/breakpoint trap) HardFault_Handler() at stm32f4xx_it.c:103 0x8053c22 <signal handler called>() at 0xffffffed 0x3810180 mbedtls_ecp_point_free() at ecp.c:594 0x8029c7a 0x81030100 It crashes properly i.e. invalid opcodes etc. There is a fair bit on google with others having gone down the same road, never resolved. One site which does it is socata.org but quite a few others do it. Probably 10% of "major name" websites cause it to crash. It may have been undiscovered for a long time, or ever, because most MbedTLS clients are connecting to specific private servers only. People aren't using it to connect to microsoft.com (which doesn't actually crash but the handshake returns 0x2700 which can be investigated). There is a Windows build of MbedTLS (v2.16.2) which seems to work in the crashing cases. Stepping through this in Cube IDE (32F417) it looks like the crash is due to a buffer being filled with random numbers. The guy working on this is contactable only on Monday afternoons so I am a bit screwed :) He said he found something about that buffer, or maybe a corrupted function pointer. But as I said this issue has come up before according to numerous online searches and maybe someone can recognise it. Hardware AES is enabled but this occurs with software AES also. No other 32F417 hardware crypto features are used, other than its random number generator. TLS is v2.16.2. Thank you in advance for any pointers. Peter

2 years, 4 months

3
9
0 0

Reminder: MBed TLS Technical Forum - Asia

by Don Harbin

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech forum is next *Monday, Dec 5 at 10:00am UK time*. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. As usual, if anyone has any topics, please let Dave Rodgman, cc'd, know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 4 months

1
0
0 0

RSA signature with Montgomery

by Prasad Hegde

Hi, Is there any API's available to convert the RSA signature to the Montgomery format. Thanks Prasad

2 years, 5 months

1
0
0 0

Code style discussions

by David Horstmann

Hi All, Mbed TLS is planning to move to a new code style by the end of this year. The proposed new style is currently being discussed in the GitHub pull request: https://github.com/Mbed-TLS/mbedtls/pull/6591 If you have any feedback on this new style, or you think we should tweak it, feel free to comment on the pull request. We will take your thoughts into account when we decide on the final style. Discussions will continue until the evening of THIS FRIDAY (UK time). Many thanks, David Horstmann for the Mbed TLS Team

2 years, 5 months

1
0
0 0

Reminder: MBed TLS Technical 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:30 PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 5 months

1
0
0 0

Certificate Verify in Client Authentication does not work as expected

by Simon Nachtigall

Hello everyone, We observed a strange behavior in the mbedTLS client, when client authentication is requested by the TLS server. This behavior was observed in the newer version 3.0.0 as well as in older versions. The scenario is the following: The server selects a ciphersuite e.g. ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and sends a CertificateRequest message that only includes the ecdsa_secp256r1_sha256 signature algorithm. However, the mbedTLS client simply ignores the requested hash function and uses ecdsa_secp256r1_sha384 for the signature in the ClientVerify. Then, the server complains since the signature does not match with the requested signature algorithm and sends a handshake failure. It seems that mbedTLS does not store the requested signature algorithms/hash function from the CertificateRequest and always uses the hash function from the selected ciphersuite. In the ssl_write_certificate_verify function, we find the following comment: /* * digitally-signed struct { * opaque handshake_messages[handshake_messages_length]; * }; * * Taking shortcut here. We assume that the server always allows the * PRF Hash function and has sent it in the allowed signature * algorithms list received in the Certificate Request message. * * Until we encounter a server that does not, we will take this * shortcut. * * Reason: Otherwise we should have running hashes for SHA512 and * SHA224 in order to satisfy 'weird' needs from the server * side. */ Is this a known problem and is there any fix available? Cheers, Simon Nachtigall

2 years, 5 months

2
1
0 0

Reminder: MBed TLS Technical Forum - Asia

by Don Harbin

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech forum is next *Monday, Nov 7 at 10:00am UK time*. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman, cc'd, know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 5 months

1
0
0 0

Simple question about support of TLS1.2 and TLS1.3 on server side

by caoyxsh＠outlook.com

Is there a plan for adding support of TLS 1.2 and TLS 1.3 at same time on server side? According to : https://github.com/Mbed-TLS/mbedtls/blob/development/docs/architecture/tls1… only one version can be configured at runtime via `mbedtls_ssl_conf_{min,max}_tls_version` for a server endpoint.

2 years, 5 months

1
0
0 0

Get size of available application data without calling mbedtls_ssl_read()

by Bruckner, Jan

Hi all, I'd like to know if there is some way to retrieve the currently available number of bytes of application data without calling mbedtls_ssl_read()? I'm writing a "TLS socket" for higher layers to use and would like to notify them when new application data is available, tell them how much it is, but leave it up to them when and how much to retrieve. I'd like to prevent having to buffer all application data inside my TLS socket, because that would mean copying it once from mbedtls' buffer to my socket and then again from there to the application whenever it actually requests the data. After a quick look into the sources, it seems like, if at all, this might be possible for single records. But all related fields are private and I could not find any API for this. Issue #551 [1] seems related, but is more about peeking into the application data, while I would be fine with knowing just the size of available application data. Thanks for any hints on how I could achieve this. Best regards, Jan [1] https://github.com/Mbed-TLS/mbedtls/issues/551 ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

2 years, 5 months

1
1
0 0

Feedback requested: Mbed TLS builds with PSA and legacy implementations of the same algorithm with different characteristics

by Gilles Peskine

Hello, Summary: I am soliciting feedback about builds of Mbed TLS where *there is both a PSA implementation and the built-in software implementation of the same algorithm, by design, *and the PSA implementation isn't just calling the built-in implementation because the two have different characteristics, each desirable in some context. Please read this message if you are doing this or considering it. Feel free to ignore otherwise. For example, both MBEDTLS_SHA256_C and MBEDTLS_PSA_ACCEL_ALG_SHA_256 are enabled, so that calls to mbedtls_md_xxx() use the software implementation and calls to psa_hash_xxx() use the hardware accelerator via the PSA driver. And this is deliberate: there is a reason why mbedtls_md_xxx() must not call the PSA driver. In most cases, this is not desirable: if there's an accelerator, why not use it? And we're working to allow getting rid of the software implementation in more and more cases. Ultimately, PSA will be the only crypto interface in Mbed TLS, so all interfaces to calculate SHA-256 will go through psa_hash_xxx() and therefore will dispatch the call to the driver if there is one. This will be an API break, since it will require calling psa_crypto_init() before performing any cryptography. Currently we are planning to introduce this requirement in Mbed TLS 4.0. But it is currently possible to have dual algorithm support, and I can think of unusual cases where it might desirable. Scenario 1, with accelerator drivers: there is a driver, but it can only be used after some initialization. The application needs to use the algorithm before calling psa_crypto_init(), so it calls the legacy interface. After psa_crypto_init() has been called, the application would like to use the driver as much as possible. A typical use case is a bootloader which wants to verify a signature before initializing the random generator, so it calls mbedtls_md_xxx() and mbedtls_rsa_xxx(). Scenario 1 is clearly desirable, and for that we have a planned solution, which is staged initialization. The bootloader will be able to (1) initialize drivers, (2) perform a hash calculation, (3) initialize the keystore, (4) verify a signature, all without initializing the RNG. We won't make psa_crypto_init() mandatory until this feature is implemented. Scenario 2: with a cryptography service. This is a build of Mbed TLS with MBEDTLS_PSA_CRYPTO_CLIENT, so all psa_xxx() calls call the service. But, for some reason, there is also a local implementation of some cryptography algorithms. So you can call mbedtls_md() to calculate a hash even before the connection to the service has been established. Or maybe you want to call mbedtls_md() for short messages and psa_hash_compute() for long messages, because the crypto service has a faster implementation but the communication overhead offsets the gain for short messages. We are currently working on improving support for PSA drivers, and in particular, saving code size by eliminating more unnecessary code when a driver is present, and increasing the set of APIs that benefit from drivers. The obvious way to do that is to make all cryptography calls (especially from X.509 and TLS) go via the PSA interface, but we can't do that yet due to the need to have initialized the keystore and RNG. We are considering routing /certain/ crypto calls via PSA, in a way that would break scenario 2, and would also break scenario 1 in some cases, but not for hashes or signature verification. If, for example, in Mbed TLS 3.4, mbedtls_md() starts calling psa_hash_(), would this break your code? Are you in scenario 1, scenario 2, or some other variant I haven't thought of? If so, *please reply to this message and let us know what your needs are*. Feel free to reply to me in private if you don't want to discuss this publicly (I won't share directly outside Arm, but the eventual design might leak information about the unusual scenario). If we don't hear objections, there is a chance that a future Mbed TLS 3.x will break scenarios 1 and 2. If we do hear objections, we'll work to keep the current behavior or arrange a migration path. Best regards, -- Gilles Peskine Mbed TLS developer

2 years, 5 months

1
1
0 0

problem PSA_CRYPTO (Mbedtls 2.28.0)

by xlin＠murata.com

I have port mbedtls 2.28.0 into my platform and am able to connect to a few websites in PKI mode. But after enabling MBEDTLS_USE_PSA_CRYPTO & MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG, with everything else stay the same, I can't connect to the same websites anymore. in the working case (no MBEDTLS_USE_PSA_CRYPTO), after the client (my app) sends "Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message", the server responds with "Change Cipher Spec, Encrypted Handshake Message". In the broken case (with MBEDTLS_USE_PSA_CRYPTO), after the client (my app) sends "Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message", the server doesn't respond with "Change Cipher Spec, Encrypted Handshake Message". I don't know how to debug the issue, any suggestion what my cause the server to drop off at the last step?

2 years, 6 months

1
0
0 0

How much bigger is MbedTLS 2.28.1 relative to 2.16.2? (STM 32F417 GCC)

by Peter

I may need TLS 1.3 support which I believe arrived in 2.28, or maybe a bit later. I don't want to change to TLS 3 just yet. It looks like many changes. My target is "OK" on FLASH (150k of the 350k total code size) but is tight on RAM (after allocating 50k for the MbedTLS heap, we have just 20k RAM left). Ideally I would like the very last version of v2. The problem just found is that Cloudflare is asking for TLS 1.3 which MbedTLS 2.16 does not support. But it may be that Cloudflare can fall back and the problem is elsewhere. Many thanks for any input.

2 years, 6 months

2
1
0 0

Performance tuning of SHA256 on big files

by Liu James

Hi, This is an updated post from https://github.com/Mbed-TLS/mbedtls/issues/6464, which should be posted in mbedtls mail list. My question is how to significantly improve SHA256 performance on big files (regardless of architectures). *=== Updates* I use same code with mbedtls-3.1.0 to run tests in x86, and performance is still downgraded. Mbed TLS version (number or commit id): *3.1.0* Operating system and version: * Centos-8.5, CPU 11900K* Configuration (if not default, please attach mbedtls_config.h): Compiler and options (if you used a pre-built binary, please indicate how you obtained it): *gcc/g++ 8.5* Additional environment information: *Test files and performance* CentOS-8.5.2111-x86_64-boot.iso (827.3 MB): sha256 *5 sec* CentOS-8.5.2111-x86_64-boot.iso (10.79 GB): sha256 *66 sec* Also, as advised I try to turn on "MBEDTLS_SHA256_USE_A64_CRYPTO_IF_PRESENT " and "MBEDTLS_SHA512_USE_A64_CRYPTO_IF_PRESENT" using mbedtls-3.2.0 in M1, but compiler reported the following error: CMake Error at library/CMakeLists.txt:257 (add_library): Cannot find source file: psa_crypto_driver_wrappers.c Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm .h .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc CMake Error at library/CMakeLists.txt:257 (add_library): No SOURCES given to target: mbedcrypto Thanks for your help. *=== Original message at github* Summary sha256() and sha1() incurs significant overhead on big files(~1G above). *This might not be an issue*, and I'm looking for an efficient way to calculate hash on big files. System information Mbed TLS version (number or commit id): 3.1.0 Operating system and version: M1 OSX Configuration (if not default, please attach mbedtls_config.h): Compiler and options (if you used a pre-built binary, please indicate how you obtained it): Clang++ Additional environment information: Expected behavior Fast calculation of big files in less than 1 second Actual behavior Test files: CentOS-8.5.2111-x86_64-boot.iso (827.3 MB): sha1 *3.3 sec*, sha256 *5.9 sec* CentOS-8.5.2111-x86_64-boot.iso (10.79 GB): sha1 *40 sec*, sha256 *78 sec* Steps to reproduce ISO files can be downloaded at: http://ftp.iij.ad.jp/pub/linux/centos-vault/8.5.2111/isos/x86_64/ Make sure use fast disk, say nvme, to store ISO files, or else loading big files could take lots of time. Also use user from time command to measure performance. Workable code of sha256: string test_sha256(string file_path) { mbedtls_sha256_context ctx; FILE *fp; string output; int BUFFER_SIZE = 4096; uint8_t buffer[BUFFER_SIZE]; size_t read, k_bytes; uint8_t hash[32]; mbedtls_sha256_init(&ctx); mbedtls_sha256_starts(&ctx, 0); fp = fopen(file_path.c_str(), "r"); if (fp == NULL) { mbedtls_sha256_free(&ctx); return output; } while ((read = fread(buffer, 1, BUFFER_SIZE, fp))) { mbedtls_sha256_update(&ctx, buffer, read); } mbedtls_sha256_finish(&ctx, hash); mbedtls_sha256_free(&ctx); fclose(fp); // update hash string, omit here return output; }

2 years, 6 months

4
5
0 0

Is there a server somewhere which can be used for testing various MbedTLS client cipher suites

by Peter

Hi All, There are machines out there for testing servers but I don't know of one which can be used for testing a client. This is a tricky area. For example I have a board running, LWIP and MbedTLS, uploading little test files to two sites. One was running EC and AES256. It worked fine. The other was running RSA and AES256 but didn't work, and after some work it was found that its certificate chain was running SHA-1 on the top level certificate, dated 2006. This is actually a major name on the internet! And we didn't have SHA-1 enabled because it is supposed to be deprecated. I wonder if there is some practical way to test out all this. We can probably enable all the MbedTLS crypto options (TLS is taking up 150k out of 350k of code for the whole product, but we can probably throw in some more) but testing them is something else. There is a test suite in TLS but it needs to be embedded in the product itself. Has someone implemented that code on a server somewhere? Thank you in advance for any pointers. Peter

2 years, 6 months

1
0
0 0

Error about psa_crypto_init

by 韩轾

I meet a problem when I call function `psa_crypto_init`, it return error code -148 that was PSA_ERROR_INSUFFICIENT_ENTROPY. I track this function step by step and found it caused by MBEDTLS_ERR_ENTROPY_NO_SOURCES_DEFINED. Code in entropy.c, if( ctx->source_count == 0 ), return this error. My question: I run code on Ubuntu, it runs well. But in some arm board, it returns this error. Why this count will be 0 sometimes? What is the root cause of this error.

2 years, 6 months

2
1
0 0

Reminder: MBed TLS Technical 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:30 PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 6 months

1
0
0 0

PKCS#7 format of certificate

by Subramanian Gopi Krishnan

Hi, I have developed a TLS and EST client application. Where the EST server issues the certificate in PKCS#7 format. It seems mbedtls library not support certificates in PKCS#7 format. Is there any plan to support PKCS#7 in future? Thanks, Gopi Krishnan

2 years, 6 months

1
0
0 0

Reminder: MBed TLS Technical Forum - Asia

by Don Harbin

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech forum is next *Monday, Oct 10 at 10:00am UK time*. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman, cc'd, know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 6 months

2
1
0 0

Re: Writing mbedtls_x509_crt chain to PEM ?

by Nicolas Pillot

Hello Please note that this is a repost from my previous message from yesterday as it seemd to have bugged (empty text + html attachement) when viewed from the archive. Apologies. Short question : how do i output an in-memory mbedtls_x509_crt chain to PEM text ? Context : I have a project where the user provides a PEM bundle to be used for HTTPS As it is provided by a user, may be incomplete or malformed : - no private key - more than 1 private key - no certificate at all - duplicate certificates - no certificate matching the private key - broken chain - extraneous certificates not part of the chain… So i want to full validate user input. Here is what i have succeeded so far : - parse the bundle into atomic parts, based on « BEGIN/END » labels - try to mbedtls_x509_crt_parse / mbedtls_pk_parse_key each part (no chain) - check that i only have one private key in the bundle - search for the certificat C matching the private key - starting from that atomic certificate, verify it against each other candidate certificate - if it validates, add it to the chain of C, and repeat until no candidate validates - then check that there are no remaining certificate (which never validated anything) - finally print and store the chain (as it’s now deemed correct and minimal) Now i want to store it in PEM format for later use. But i do not understand the way to do it : - there are no write functions for mbedtls_x509_crt - the mbedtls_x509write_cert structure shares few members with mbedtls_x509_crt - i have not found yet how to get/convert many of the missing members - as memory is tight i have have cleaned the « atomic parts » text buffers (but if there is no other way, i'll keep and reuse them) I guess it should be pretty simple, but i cannot wrap my head around it. Thanks in advance for your help Nicolas PS : if steps 1-8 could be done more elegantly, please do not hesitate to point me in the right direction.

2 years, 6 months

1
0
0 0

Writing mbedtls_x509_crt chain to PEM ?

by Nicolas PILLOT

2 years, 6 months

1
0
0 0

Mbed TLS4.0 - Remove legacy cipher APIs

by S Krishnan, Archanaa

Hi, In mbedTLS road map, there is a future task to remove legacy cipher API (https://developer.trustedfirmware.org/w/mbed-tls/roadmap/). Does that mean all existing mbedtls crypto APIs will not be supported anymore? mbedTLS is used for both its TLS and crypto library. I am curious how the planned changes will affect both set of users. * Are the crypto library users expected to only use PSA crypto APIs and key IDs? * Are the TLS library users expected to see API changes to TLS functions to support key IDs? Thank, Archanaa

2 years, 7 months

4
3
0 0

Question about handshake MTU

by Martin Man

Hi guys, I use mbedtls for years (since 2.10 IIRC) upgrading to latest available as time goes by. For DTLS that is. I remember a case in the past where a link would have a small MTU (around 500 bytes) and I had to tune ssl_context.handshake.mtu to a lower value to successfully complete handshakes. I do not remember exactly why, but I did not want to actually restrict maximum value via mbedtls_ssl_set_mtu, maybe it was even ignored back then for handshakes… but Now when working on migration to 3.2.1 (gave some time to 3x releases to stabilize) I noticed that the whole ssl_context.handshake member is now private and inaccessible, which I guess is fine. Could somebody with more knowledge of the code recommend what is the best strategy for DTLS app where MTU may not always be 1400? thanks a lot for your time, Martin

2 years, 7 months

4
7
0 0

Regarding Connection ID (RFC 9146) support in Mbed TLS

by Jérémy Audiger

Hi everyone, I would like to know what is the current support of Mbed TLS regarding the RFC 9146 (https://datatracker.ietf.org/doc/html/rfc9146) published in March 2022. Mbed TLS is currently supporting a draft version of this RFC (https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls-connection-id-05) through the define MBEDTLS_SSL_DTLS_CONNECTION_ID, but I just wanted to know the progress on supporting the newly RFC released this year. Are there any plan to support it soon ? If yes, will it be in the coming weeks / months (i.e.: next release) ? I'm asking since I'm currently playing with the Connection ID on both a DTLS 1.2 Server and DTLS 1.2 Client. Anyway, have a nice day, Best regards, Jérémy Audiger [ioterop-your-lwm2m-partner]<https://ioterop.com/> [social-icon-linkedin]<https://www.linkedin.com/company/7955832/> [social-icon-twitter] <https://twitter.com/ioteropcompany> [social-icon-facebook] <https://www.facebook.com/IoteropCompany/>

2 years, 7 months

2
1
0 0

Reminder: MBed TLS Technical 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:30 PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 7 months

1
0
0 0

Re: What am I doing wrong?

by Marco Nilsson

We're seeing pretty much the same issue on 3.0.0 ARM. However, if I build the ssh_client2 tool on my host machine (x64) and try to mimic the config as close as possible, it works just fine. Do you think we're seeing the same problem? Will try with a newer version next week.

2 years, 7 months

1
0
0 0

HMAC and CMAC Verification

by Ahmed Mohammed

Hello, I am wondering if there are APIs for Hmac and Cmac verification? from md.h and cmac.h, Hmac and Cmac generation functionalities are provided in a single and streaming approach. But is there a plan to add verification APIs for future releases maybe? Kind regards, Ahmed Mohammed

2 years, 7 months

2
1
0 0

User configuration

by Ahmed Mohammed

Hello, What is the difference between these two macros in include/mbedtls/build_info.h: MBEDTLS_CONFIG_FILE MBEDTLS_USER_CONFIG_FILE In other words, why would I have two different user configuration files? Or I misunderstand the difference between such files. Kind regards, Ahmed Mohammed

2 years, 7 months

2
1
0 0

Slowness in verification of a ecdsa secp256r1 signature using S32K Microcontroller (clock speed 112MHz) - bare metal implementation

by ammar.ahmed.mughal＠gmail.com

I am verifying a signature generated using ecdsa secp256r1. The signature is getting verified but the time taken by the verification step is too long. It takes 4-5 seconds to verify the signature. The implementation is bare metal i.e. no RTOS (one realizes the use of RTOS but still the time is too long). Can you please guide a way around for this issue. How to make it work faster , the ideal verification time would be 30ms - 60ms. Here is a gist of my code mbedtls_ecp_curve_info *curve_info = NULL; mbedtls_ecdsa_context ecdsa_context; /// Initialization mbedtls_ecdsa_init(&ecdsa_context); curve_info = mbedtls_ecp_curve_info_from_tls_id(23); /// 23 is tls_id of secp256r1 mbedtls_ecp_group_load(&ecdsa_context.grp, curve_info->grp_id); /// Processing result = mbedtls_ecp_point_read_binary( &ecdsa_context.grp, &ecdsa_context.Q, public_key_data, // public key data in uncompressed format i.e. including leading 0x04 sizeof(public_key_data) ); /// 32 /// 71 status_verify_signature = mbedtls_ecdsa_read_signature(&ecdsa_context, hash, sizeof(hash), signature, sizeof(sig)); /// converts the signature data to ASN1, verifies the signature Thank you :)

2 years, 7 months

2
1
0 0

Mutual authentication support in Embed tls

by Anupma Jain

Hello, Can please provide me with any example on "how to achieve Mutual authentication(Client and server certificate validation)" in mbed-tls. Please help me with this.It is a little urgent. Thank you Regards Anupma Jain

2 years, 7 months

1
0
0 0

Website update

by Dave Rodgman

Hi all, Apologies for the website outage. We have now restored the majority of the old content, which is reachable via our Trusted Firmware website (the old website address will redirect here). The new location for our documentation, including the knowledge base and security advisories, is: https://mbed-tls.readthedocs.io/en/latest/ Please let us know (on the mailing list, via the Tech Forum, or raise a GitHub issue or PR) if you find any issues or missing documentation. The source repository for the docs is here: https://github.com/Mbed-TLS/mbedtls-docs Community contributions to the docs are welcome! Regards Dave Rodgman

2 years, 7 months

2
1
0 0

OID Issue

by Subramanian Gopi Krishnan

Hi, We have developed a propriety protocol that authenticate node using certificate. In our PKI, we have four level of certificates as ROOT_CA, PROXY_CA, LOCAL_CA, and DEVICE_CERTIFICATE. Parsing of trusted CA certificate is getting success. However, verifying PROXY_CA against ROOT_CA fails with below error code. MBEDTLS_ERR_X509_UNKNOWN_SIG_ALG + MBEDTLS_ERR_OID_NOT_FOUND I have viewed the certificates transacted using OpenSSL command, the ASN1 OID is ECDSA_SHA384. Though, I have enabled the algorithm, it is failing. Any support would be appreciated. Attached the config.h for your reference. Thanks, Gopi Krishnan

2 years, 8 months

1
0
0 0

Adding option to disable the zeroisation of internal buffers

by joel.petersson＠dirac.com

After recently updating mbedtls I noticed a considerable slowdown (over 70% on my cortex-m7 board) in the sha256 implementation, and after some digging I found the offending commit: https://github.com/Mbed-TLS/mbedtls/commit/76749aea784cfec245390d0d6f0ab0a2… I understand the motivation behind the commit, but I think it may not be relevant to all use cases. So my question is if an option to disable the clearing of internal buffers in mbedtls_config.h would be a reasonable improvement? Or would that be considered to much of a foot gun? Regards, Joel Petersson

2 years, 8 months

4
7
0 0

support of Certificate exchange between client and server in Mbedtls

by Anupma Jain

Hi, In Embed tls version 2.28, is there any support to validate client certificate fields like for example: validity of certificate, CA validation or role extraction ? If support is present then, how can we enable that ? Please help me with this.Thanks in advance. Regards Anupma

2 years, 8 months

1
0
0 0

Reminder: MBed TLS Technical 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:30 PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 9 months

1
0
0 0

totally beginner question...

by boddeke＠mac.com

hello, we are testing a secure communication and got example code that uses the mbed-tls library. i am using the online keil studio with mbed.org: created a new project (compiles fine) and added in the mbed-tls library but this already gives compile errors. see below. i am using the latest greatest versions (mbed-os 6.16.0 and mbedtls-3.2.1) and tried some older versions. all seem to give the same problems. see below. i have tried commenting out MBEDTLS_HAVE_TIME in mbedtls_config.h but that does not seem to make any difference tried different target boards, also no difference any help is greatly appreciated! thanks frank Build started Using toolchain ARMC6 profile {'ENV': {'ARMLMD_LICENSE_FILE': '8224@10.10.101.194:8224@10.10.109.222'}, 'PATHS': {'ARMC6_PATH': '/opt/ARMCompiler6.15.13/bin/', 'ARM_PATH': '/opt/armcc5_06_u6/'}, 'common': ['-c', '--gnu', '-O3', '-Otime', '--split_sections', '--apcs=interwork'], 'cxx': ['--cpp', '--no_rtti'], 'COMPILE_C_AS_CPP': False, 'NEW_SCAN_RESOURCES': True} scan /tmp/chroots/ch-59110c86-ee99-44c4-9ef0-79f3efde74a7/src scan /tmp/chroots/ch-59110c86-ee99-44c4-9ef0-79f3efde74a7/extras/mbed-os.lib compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Config/RTX_Config.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/TOOLCHAIN_ARM/TARGET_RTOS_M4_M7/irq_cm4f.S compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_evflags.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_lib.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_mempool.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Library/cmsis_os1.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_evr.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_memory.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_delay.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_msgqueue.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_kernel.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_mutex.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_semaphore.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_system.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/Source/os_systick.c compile mbed-os/cmsis/CMSIS_5/CMSIS/TARGET_CORTEX_M/Source/mbed_tz_context.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_timer.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/Source/os_tick_ptim.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_thread.c "time.h included in a configuration without MBEDTLS_HAVE_TIME" unknown type name 'time_t'; did you mean 'size_t'? unknown type name 'time_t'; did you mean 'size_t'? unknown type name 'time_t'; did you mean 'size_t'? compile mbed-os/cmsis/device/rtos/source/mbed_rtos_rtx.c In file included from /extras/mbed-os.lib/cmsis/device/rtos/source/mbed_rtos_rtx.c:23: In file included from /extras/mbed-os.lib/platform/include/platform/mbed_error.h:21: In file included from /extras/mbed-os.lib/platform/include/platform/mbed_retarget.h:107: /src/mbedtls/tests/include/baremetal-override/time.h:18:2: error: "time.h included in a configuration without MBEDTLS_HAVE_TIME" #error "time.h included in a configuration without MBEDTLS_HAVE_TIME" ^ In file included from /extras/mbed-os.lib/cmsis/device/rtos/source/mbed_rtos_rtx.c:23: In file included from /extras/mbed-os.lib/platform/include/platform/mbed_error.h:21: /extras/mbed-os.lib/platform/include/platform/mbed_retarget.h:669:5: error: unknown type name 'time_t'; did you mean 'size_t'? time_t st_atime; ///< Time of last access ^~~~~~ size_t /opt/ARMCompiler6.15.13/bin/../include/stdio.h:53:26: note: 'size_t' declared here typedef unsigned int size_t; /* see <stddef.h> */ ^ In file included from /extras/mbed-os.lib/cmsis/device/rtos/source/mbed_rtos_rtx.c:23: In file included from /extras/mbed-os.lib/platform/include/platform/mbed_error.h:21: /extras/mbed-os.lib/platform/include/platform/mbed_retarget.h:670:5: error: unknown type name 'time_t'; did you mean 'size_t'? time_t st_mtime; ///< Time of last data modification ^~~~~~ size_t /opt/ARMCompiler6.15.13/bin/../include/stdio.h:53:26: note: 'size_t' declared here typedef unsigned int size_t; /* see <stddef.h> */ ^ In file included from /extras/mbed-os.lib/cmsis/device/rtos/source/mbed_rtos_rtx.c:23: In file included from /extras/mbed-os.lib/platform/include/platform/mbed_error.h:21: /extras/mbed-os.lib/platform/include/platform/mbed_retarget.h:671:5: error: unknown type name 'time_t'; did you mean 'size_t'? time_t st_ctime; ///< Time of last status change ^~~~~~ size_t /opt/ARMCompiler6.15.13/bin/../include/stdio.h:53:26: note: 'size_t' declared here typedef unsigned int size_t; /* see <stddef.h> */ ^ 4 errors generated. Internal error. Build failed Build failed

2 years, 9 months

1
0
0 0

misc. questions

by Frank Bergmann

Hi all, I have some questions. 1) If you have an established TLS connection (mbed TLS 3.x) and while the connection is up the (server-) certificate expires: Will the connection stay up? Or is a new handshake (with valid cert) REQUIRED? 2) Related to question 1: CAN mbed TLS switch to a new cert on an existing TLS connection? (e.g. by doing another handshake from server OR client side) 3) With 3.x some struct members are now "private". Even if you can allow private access by a define it would be better to use a getter. But for ssl context's "state" I am missing this and also for "p_bio" (to access fd). Is there a chance to get this implemented? BTW - a big "LIKE" for 3.x! I really appreciate the changes. Thank you! kind regards, Frank

2 years, 9 months

5
6
0 0

inline assembly MULADDC_CORE for Cortex M4

by Work Only

Hello everyone, Can anyone share some example code or hints on writing MULADDC_CORE for Cortex M4 in bn_mul.h? With Many thanks! Wade

2 years, 9 months

1
0
0 0

Reminder: MBed TLS Technical Forum - US/Europe

by Don Harbin

Hi All, A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum is tomorrow (Monday) at 4:30 PM UK time. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 9 months

1
2
0 0

[Mbed-tls-announce] Mbed TLS 3.2.1 release

by Paul Elliott via Mbed-tls-announce

Hi Mbed TLS users, We have released Mbed TLS version 3.2.1. This release is functionally identical to 3.2.0, but includes a file that was missing from the 3.2.0 release (see https://github.com/Mbed-TLS/mbedtls/issues/6084). Full details are available in the release notes (https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.2.1). We recommend all users to consider whether they are impacted, and to upgrade appropriately. Many thanks, Mbed TLS Team. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

2 years, 9 months

1
0
0 0

Release of Mbed TLS 3.2.0 and 2.28.1

by Dave Rodgman

Hi Mbed TLS users, We have released Mbed TLS versions 3.2.0 and 2.28.1. These releases of Mbed TLS address several security issues, provide bug fixes, and for 3.2.0, add various features. Full details are available in the release notes (https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.2.0, https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.1). We recommend all users to consider whether they are impacted, and to upgrade appropriately. Dave Rodgman

2 years, 9 months

1
0
0 0

What is the URL to access the Mbed TLS knowledge base?

by Max Peng

Hi mbed-tls Team, I notice that https://tls.mbed.org has been directed to https://www.trustedfirmware.org/projects/mbed-tls/. However, I does not see any link to the old Mbed TLS knowledge base. It is a good resource for learning Mbed TLS. What is the URL to access it? Thanks, Max Peng

2 years, 9 months

2
2
0 0

State of documentation

by Tim Becker

Hi all, it feels like the state of documentation has deteriorated since the last time I've used mbedtls (a couple of months ago). I'm not sure if the google index hasn't fully been updated yet, or I don't understand the new structure of the docs or ... Also, is this the proper forum to make suggestions? Should I raise an issue on Github? 1.) a lot of previously linked, useful information now redirects here: https://www.trustedfirmware.org/projects/mbed-tls/ which (please excuse my frankness) feels like an utterly useless abomination that only marketing people could love. - Some examples of previously useful links: from the wiki ( https://developer.trustedfirmware.org/w/mbed-tls/) : > Old Mbed TLS website > Documentation: Mbed TLS API Reference; Knowledge base; Dev corner all redirect to trustedfirmware.org ! As do nearly all the links in https://github.com/Mbed-TLS/mbedtls/blob/development/SUPPORT.md 2.) there is no longer an doxygen generated API documentation anywhere only. I could generate it myself, but then I'd need to get and install Doxygen, figure how to use it, etc. It would be great if this were restored. It can't be that expensive to host :) Anyway, it feels like I've been running around for hours trying to find _anything_ useful, but I just realized everything is redirected to trustedfirmware.org ... Is there any way to still access the old, useful docs? Thanks & sorry that this post is so negative, -tim

2 years, 9 months

6
8
0 0

TLS Handshake failure while connecting to mqtt broker from device

by urvi＠milltech.in

Hello Sir/Madam, I am developing TI's EFM32 series micro controller based IOT device. This device will connect to mqtt broker and publish/ subscribes to/from data. In my application, I am trying to connect to AWS using mbedtls library over lwIP (no rtos mode). While my device is in debug mode (i.e. JTAG programmer connected) then it gets connected to AWS successfully. But when I remove JTAG programmer and operate device in normal running mode, then it failed to get connect to broker (i.e. AWS). I observe following errors occured while performing TLS handshaking stage: SSL - The connection indicated an EOF X509 - Certificate verification failed, e.g. CRL, CA or signatur SSL - Processing of the ServerHello handshake message failed

2 years, 9 months

1
0
0 0

Setup to test and debug a single funciton.

by Victor Micó

Hi all, First of all apologies if this is not the right place for this topic. For my master thesis I am using the mbedtls library to analyze it using side channel analysis. My objective was to use it as a starting point to analyze the resistance of different exponentiation algorithms. With this objective I am trying to set up a environment where I can call the function "mbedtls_mpi_exp_mod" https://github.com/Mbed-TLS/mbedtls/blob/f5b7082f6e8af72868966b6ea99eae228f… and debug it. I have been trying for at least two weeks but I couldn't be able to succeed. I believe that when If I can get a debugging environment for that function I will be able to adapt it and use other exponentiation algorithms such as the Left-to-right k-ary (HAC 14.82). I am using VScode and the code is located in WLS Ubuntu 20.04. So far I been able to compile the full library and run all the tests. Anyone here could give mean indication on how to set up the environment to debug this function? Thanks! Victor.

2 years, 9 months

1
0
0 0

Looking for information regarding the long-term support of the MbedTls library.

by heinrich.mueller＠g-ushin.com

Hello, Currently, we are evaluating the MbedLib to be eventually used in small and midsized automotive ECUs. * Since we have to follow the UNECE Regulation R155, R156, and ISO/SAE 21434 I need some information regarding the long-term support of the library and how the communication of bugs is organized? * I also do not understand the involvement and responsibility of ARM company? * Furthermore, I'm not sure if I understood the terms PSA and MbedTls and their mutual dependencies as well as the technical meaning? I checked the web for I but did not find anything about it yet. It would be just great if somebody can give me some hints or links to the information I am looking for. Regards Heico

2 years, 9 months

2
1
0 0

How to secure two simultaneous sockets?

by Fred Wedemeier

I have an application using mbedTls 2.9.0 that's been running successfully for a few years. It secures connections for the AWS MQTT broker, for https GET/PUT transfers, and for SSL/TLS email servers - But only one secure connection at a time. I need to add support for an FTPS client. This requires opening/securing a control channel on port 21, then opening/securing a second port for data transfer. Opening/securing the control channel works as expected. Then, when the client calls connect() for the data transfer socket, the server log shows messages indicating it is preparing for a TLS handshake. Now, here's where I may be missing something... The client calls the same code as for the control connection: Allocates a second mbedtls_ssl_context, mbedtls_ssl_config, mbedtls_x509_crt, et.al, and calls some mbedtls_ssl_*() functions which were copy/pasted from example code several years ago. The server name and root cert are the same. I think the only difference in the second negotiation is the underlying socket descriptor allocated by the IP stack for the data channel. When mbedtls_ssl_handshake() is called, both the filezilla log and client log show a successful handshake. The filezilla log then shows it trying to establish yet another secure data connection, which fails, and reports "TLS session of data connection not resumed." Questions: -- Is the above sequence correct for opening and securing a second connection? -- In searching through ssl.h I see mbedtls_ssl_get_session() and mbedtls_ssl_set_session(). Are these relevant to the situation? I cannot tell from their one-sentence descriptions.

2 years, 9 months

1
0
0 0

How to use just RSA algorithm in the tls library with stm32

by arman_ilmak＠yahoo.com

Hi I just needed to use rsa.c but its a little complicated. Can anyone help me or give me any document about how i can use it without use of tls. I just saw a doc on tls.mbed.org but the site is not working anymore.

2 years, 9 months

1
0
0 0

psa_crypto_init() asks for entropy even it is not needed for every use case

by heinrich.mueller＠g-ushin.com

Hello, currently, I am evaluating the mbed-tls. I already created some smaller demos regarding AES and RSA. I do so on a PC with cygwin and with Keil micro vision for a NXP S32K144. One demo is just validating some data with a signature and an existing public key. Here is the point that puzzles me a bit. As far as I understand this cybersecurity stuff entropy is not needed for the above use case. Some of my colleagues would agree with me. Once psa_crypto_init() is called on a target NXP S32K144 the function returns PSA_ERROR_INSUFFICIENT_ENTROPY. So far so good https://os.mbed.com/docs/mbed-os/v6.15/porting/entropy-sources.html gives the hints on how to handle this in general but I did not find any information on how to disable the "request for entropy" in a save way once your use case does not need any new secrets. Can you give me a hint why psa_crypto_init() is implemented that way? It may also be that I still have a conceptual understanding problem!? Regards Heico

2 years, 9 months

2
2
0 0

*_ALT vs PSA for HW crypto and upstreaming

by mathieu.rondonneau＠broadcom.com

Hi mbed-tls Team, PSA crypto API for HW acceleration seems pretty new. Question1: is there some reference code or project I could poke around to see how it is being used? Currently I have added (locally) a set of driver to make use of our HW crypto using the *_ALT way (the old way?) and for what I understand, the PSA API is the "new way" to do things. But It is still unclear how vendor do upstream there HW acceleration drivers. If this part is kept in another repo, then the mbedTLS build does not have any "hooks" to pull-in the vendor specific code to build the mbedTLS library with. The current implementation seems to be agnostic to any vendor specific HW so I am wondering if there is a "standard" way for vendor to upstream their mbedTLS HW acceleration code that would be built as part of mbedTLS library. I have posted a similar thread to the "issue" ticket of the mbedtls repo for reference: https://github.com/Mbed-TLS/mbedtls/issues/5975 Thanks for any feedback/pointers/ideas. Regards, -Mathieu

2 years, 10 months

3
2
0 0

LWIP/MbedTLS - any idea if SPI SRAM (block-accessible RAM) could be used for buffers?

by Peter

Hi All, My target has 128k SRAM which has about 60k spare, and 64k CCM which is allocated whole to FreeRTOS stacks etc (its private heap, memory model #4). I am running a simplified HTTP server (for local config etc), which uses fairly minimal RAM (a few k), and an HTTPS/TLS client which uses about 50k (for its private heap). So if both of the above are running concurrently, there is only ~10k RAM left, but it does work, but when TLS is doing its handshake/negotiation (which on a 168MHz 32F417 takes 2-3 seconds) the HTTP server temporarily hangs. Investigating this, it appears that LWIP is running out of buffers during TLS and is rejecting incoming packets. I don't really want to change the CPU to the next one up which has another 64k RAM, because a) I have stock of the 417 and this took about a year to get, b) the design is rock solid and I don't want to tempt fate (there is a lot of subtle hardware usage e.g. DAC ADC DMA timers) even though in theory it should be just alternate function pin changes, c) some versions of the product may not need TLS at all. I have an option of an 8 megabyte SPI-attached RAM https://www.eevblog.com/forum/microcontrollers/lyontek-ly68l6400-8-megabyte… which does work and is not bad at $3 (there are cheaper 128kbyte versions too), but obviously cannot be addressed as normal RAM. The ESP32 can do that but the 32F4 can't. Does anyone know enough about the internals of MbedTLS, or even LWIP, to know whether the memory usage structure lends itself to this kind of "overlay" memory? One can read or write say 1k bytes in 400us, in my target (21MHz SPI with DMA). Obviously this would be horribly inefficient for a byte at a time emulation but perhaps one can switch buffers in and out... Thank you in advance. If somebody knows of a concrete route, I am happy to pay for the time. Regards, Peter

2 years, 10 months

1
0
0 0

Reminder: MBed TLS Technical Forum next Monday

by don.harbin＠linaro.org

Hi All, This is a gentle reminder that the next MBed TLS Tech forum is next Monday 4:30 PM UK time. If you have any topics, please let Dave Rodgman know. :) Best regards, Don MBed TLS Technical Forum Monday Jul 4, 2022 ⋅ 8:30am – 9:30am Mountain Standard Time - Phoenix 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 nnac123(a)gmail.com

2 years, 10 months

1
0
0 0

Is tls.mbed.org down?

by Max Peng

I wanted to access Mbed TLS knowledge Base (https://tls.mbed.org/kb) but fails. It seems tls.mbed.org was down for few days. Is this a known issue?

2 years, 10 months

3
4
1 0

RFC: removing support for DHE in TLS 1.2 in Mbed TLS 4.0?

by Manuel Pegourie-Gonnard

Hi all, We're seeking feedback on our plans regarding support for Finite-Field DHE (also known as FFDH(E), as opposed to the Elliptic Curve version, ECDH(E)). Currently the PSA Crypto API only supports FFDH with named groups, which aligns well with modern cryptographic practice and the needs of TLS 1.3, but less well with TLS 1.2 where arbitrary parameters can be chosen by the server, leading to various interoperability and security issues (see the introduction of RFC 7919, hence the general move to named groups). Some data suggests that FFDH is already seeing very little use (less than 1% of TLS 1.2 traffic) on major websites, and presumably this would be even less when constrained devices are involved, since ECDH is less resource-intensive. So, we are currently planning on removing support for DHE-RSA and DHE-PSK key exchanges in TLS 1.2 in the next major version of Mbed TLS. We would retain support of ECDHE in TLS 1.2, and of DHE (in addition to ECDHE) in TLS 1.3. (Support for FFDH in TLS 1.2 would also be present in the LTS version released around the same time as the next major version.) If you have any objection to this plan, please let us know about your use case and motivations, either by responding to this email, or by commenting on the corresponding github issue: https://github.com/Mbed-TLS/mbedtls/issues/5278 Thank you! Best regards, Manuel for the Mbed TLS team.

2 years, 10 months

1
0
0 0

Verify cert chain

by Subramanian Gopi Krishnan

Hi, I have one root ca, intermediate ca, and device certificate in der format. While am trying to verify one by one as intermediate-ca with root-ca and device cert with intermediate-ca; things work fine. But if I tried to verify like having two context one for ca and one chain. I parse root ca on CA context and intermediate ca and device cert on chain context. Now verification fails with flag 8 error code -0x2700. I have attached verify_der_one_by_one.c it is working without any issue; but verify_der_chain.c is causing the issue stated above. Any help would be appreciated. Thanks, Gopi Krishnan

2 years, 10 months

1
0
0 0

VIA padlock support

by Gilles Peskine

Hello, Mbed TLS supports AES acceleration with VIA Padlock (MBEDTLS_PADLOCK_C). We do not have the hardware to test it, so this should be considered strictly community-maintained. We are making a patch to the AES module which has a small risk of breaking VIA padlock support: https://github.com/Mbed-TLS/mbedtls/pull/5896 . If you are using VIA padlock, please test this change and let us know if something's wrong. On a related note, we intend to drop the Padlock code in the next major version of Mbed TLS (https://github.com/Mbed-TLS/mbedtls/issues/5903). If you care about this feature, please let us know. Best regards, -- Gilles Peskine Mbed TLS developer

2 years, 10 months

1
0
0 0

Clear master secret from mbedtls_ssl_session after handshake is ready

by Maarten Meijer

Hi all, I'm using an mbedTLS server on a CPU with a small memory foot print. In a search to serve as many as possible TLS clients, I found that the mbedtls_ssl_session.master[48] structure member is still in memory after the handshake is over. (I filed an issue to start with, but was quickly directed to this mailing list, thanks to Tom Cosgrove. See Clear master secret from mbedtls_ssl_session after handshake is ready * Issue #5832 * Mbed-TLS/mbedtls (github.com)<https://github.com/Mbed-TLS/mbedtls/issues/5832>) I'm wondering why this is needed. The `master` secret references I can find in the code are either related to the TLS handshake, or to serialization/deserialization. I am wondering whether it makes sense to serialize/deserialize the master secret but I'm not sure if it is a use case to support serialization of ongoing handshake operations. Based on this 2 questions: * Is the master secret relevant when the handshake is over? * Is the master secret really useful in serialization/deserialization? If so, I could use `MBEDTLS_SSL_CONTEXT_SERIALIZATION` in my eventual merge request to keep facilitating this. Looking forward for relevant answers. Thanks in advance, Maarten

2 years, 10 months

2
3
0 0

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

by don.harbin＠linaro.org

You have been invited to the following event. Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: Every 4 weeks from 2am to 2:50am on Monday 20 times Mountain Standard Time - Phoenix Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin - creator * nnac123(a)gmail.com * santosdanillo(a)gmail.com * schoenle.thomas(a)googlemail.com * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MzE1cHJuZGxwMDFo… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

2 years, 10 months

1
0
0 0

Reminder: MBed TLS Technical Forum June 6th

by Don Harbin

Hi All, A gentle reminder that the next MBed TLS Tech forum is next Monday at 4:30pm UK time. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 11 months

1
0
0 0

PSA API on non-threaded environment

by gergely.nagymate＠generalmechatronics.com

Hi, I am using mbedTLS v3.0.0 on a low performance CPU on a non-threaded environment, a custom task manager, which is not a preemptive operating system. I have been using MBEDTLS_ECP_RESTARTABLE so even the long ECC calculations during the handshake periodically returned so the external logic and task manager could run without being blocked for too long. Recently an IoT SAFE implementation was introduced through PSA API. It is used for RNG and verification calculation, but not for ECDSA and ECDH during key exchange. PSA API is designed for threaded environments and can not simultaneously use MBEDTLS_ECP_RESTARTABLE. Now the ECC functions block for several seconds. Do you have a recommendation on how to use PSA on non-threaded environments, or how to inject external logic execution during these long ECC operations? Thanks, Gergely

2 years, 11 months

2
1
0 0

PSA API on non-threaded environment

by Gergely Nagymáté

Hi, I am using mbedTLS v3.0.0 on a low performance CPU on a non-threaded environment, a custom task manager, which is not a preemptive operating system. I have been using MBEDTLS_ECP_RESTARTABLE so even the long ECC calculations during the handshake periodically returned so the external logic and task manager could run without being blocked for too long. Recently an IoT SAFE implementation was introduced through PSA API. It is used for RNG and verification calculation, but not for ECDSA and ECDH during key exchange. PSA API is designed for threaded environments and can not simultaneously use MBEDTLS_ECP_RESTARTABLE. Now the ECC functions block for several seconds. Do you have a recommendation on how to use PSA on non-threaded environments, or how to inject external logic execution during these long ECC operations? Thanks, Gergely

2 years, 11 months

1
0
0 0

"RAW RSA" encoding method for signatures

by THIERRY BINIGUER

Hi all, I can see a "RAW RSA" encoding method for signatures both implemented in mbed TLS and PSA API and I'm wondering about the motivations and rational of this variant. Could you tell more about it, please ? Below details. Thierry It was introduced since 2017 in mbed TLS in this sha1 ID : fdf38030de70b95a77205f17d65591f05e74be08 ("Outsource code for generating PKCS1 v1.5 encoding"). As far as I know, standard does not specifically mention it but RFC 8017 ($9.2) specifies EMSA-PKCS1-v1_5 as a deterministic encoding method (no randomness) with a buffer that is built as an encoded message EM = 0x00 || 0x01 || PS || 0x00 || T, where PS being padding bytes, T being a DER encoding of a digestInfo, where digestInfo contains : - the hash function (so called AlgorithmIdentifier applied on the message) - and the hash value (so called digest H = = Hash(M)) PSA defines the RAW RSA in its API. It is said a signature algorithm, without hashing. In this raw RSA PKCS#1 v1.5, the hash parameter to psa_sign_hash is computed "externally". It is a DER encoding, “ready-to-use" hash, so called raw data in PSA and mbed TLS. In the RSA PKCS#1 v1.5, the hash parameter to psa_sign_hash is H (computed with the hash function as indicated in the standard). mbed TLS implementation manages RAW data in rsa_rsassa_pkcs1_v15_encode(), it copies raw data as they are given and pads accordingly. Even if from a security perspective, this variant does not seem to introduce vulnerabilities, there is no information on the used hash algorithm inside the signature itself, therefore making mandatory for the verifier to know exactly which algorithm is used, and therefore less trivial in term of device interoperability.

2 years, 11 months

2
1
0 0

Cancelled event: MBed TLS Technical Forum - Asia @ (BST) (mbed-tls@lists.trustedfirmware.org)

by Mike Holmes

This event has been cancelled. Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: United Kingdom Time Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin- creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org * nnac123(a)gmail.com * santosdanillo(a)gmail.com * schoenle.thomas(a)googlemail.com Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

2 years, 11 months

1
0
0 0

Updated invitation: MBed TLS Technical Forum - Asia @ Every 4 weeks from 19:00 to 19:50 on Monday 13 times (AEST) (mbed-tls@lists.trustedfirmware.org)

by santosdanillo＠gmail.com

This event has been changed. Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: Every 4 weeks from 19:00 to 19:50 on Monday 13 times Eastern Australia Time - Sydney (changed) Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin- creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org * nnac123(a)gmail.com * santosdanillo(a)gmail.com * schoenle.thomas(a)googlemail.com Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MmU4dm1iNzJ0dmV1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

2 years, 11 months

1
0
0 0

Updated invitation: MBed TLS Technical Forum - Asia @ Every 4 weeks from 21:00 to 21:50 on Monday from Mon 31 Jan to Mon 23 May (AEDT) (mbed-tls@lists.trustedfirmware.org)

by santosdanillo＠gmail.com

This event has been changed. Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: Every 4 weeks from 21:00 to 21:50 on Monday from Mon 31 Jan to Mon 23 May Eastern Australia Time - Sydney (changed) Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin- creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org * nnac123(a)gmail.com * santosdanillo(a)gmail.com * schoenle.thomas(a)googlemail.com Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MmU4dm1iNzJ0dmV1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

2 years, 11 months

1
0
0 0

Require cross compilation steps

by Krunal Chauhan

Hi, I need updated mbed TLS library version 3.1.0 I need step/procedure to cross compile mbed TLS library. Best Regards, [Logo]<https://www.slscorp.com/> Krunal Chauhan Senior Engineer Email: krunal.chauhan(a)slscorp.com | www.slscorp.com<http://www.slscorp.com> Plot#32, Zone-D/4, Phase-1, GIDC Estate V.U. Nagar - 388 121, Gujarat, India

2 years, 11 months

1
0
0 0

Re: AES Memory Leak

by Minos Galanakis

Hi Subramanian. Thank you for your report. Would it be possible to provide some further information on how the program is structured? Is the code snippet running in a single thread or a multithreaded application? How often is data transmitted (As to many invocations are we considering for an 8-hour window)? How is that while(1) loop interrupted? Which platform architecture is the program running at? I have been trying to reproduce it by expanding the Valgrind test suite, as to repeat the logic included in the example for UINT_MAX iterations, without success. Minos ________________________________ From: Subramanian Gopi Krishnan via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 16 March 2022 04:24 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] AES Memory Leak Hi, I have developed a program to send encrypted data continuously. The program is working fine for few hours. After 6 to 8 Hrs, I get returned MBEDTLS_ERR_CIPHER_ALLOC_FAILED -0x6180 Do I need to free the gcm context for every time I send data? What would be the root cause. #define AEAD_KEY_SIZE (32) /**< AEAD Key Size(in bytes). */ #define AEAD_IV_SIZE (12) /**< AEAD IV Size(in bytes). */ #define AEAD_AD_SIZE (16) /**< AEAD AAD Size(in bytes). */ #define AEAD_TAG_SIZE (16) /**< AEAD Tag Size(in bytes). */ #define AEAD_ID_SIZE (4) /**< AEAD Tag Size(in bytes). */ #define MAX_CIPHER_SIZE (2048)/**< AEAD Cipher/Plaintext Segent Size unoperation(in bytes). */ typedef struct { mbedtls_gcm_context CtxAead; /**< aes-gcm 3rd party library context */ uint8_t pu8Key[AEAD_KEY_SIZE]; /**< Key - Randomly Generated */ uint8_t pu8InitVector[AEAD_IV_SIZE]; /**< Randomly Generated */ uint8_t pu8AddData[AEAD_AD_SIZE]; /**< Additional Associated Data - md5sum() */ uint8_t pu8Tag[AEAD_TAG_SIZE]; /**< Hold Digest/Tag of encryped data */ uint8_t pu8Id[AEAD_ID_SIZE]; /**< KeyID is generated */ uint8_t pu8Data[MAX_CIPHER_SIZE]; /**< Buffer to hold plain-text after decipher */ uint8_t pu8Cipher[MAX_CIPHER_SIZE]; /**< Buffer to hold cipher-text after cipher */ uint16_t u16Length; /**< Current length of buffer to encrypt/decrypt */ }S_Aead; int32_t i32Aead_EncryptionCycle(S_Aead *ctx ,uint8_t *pu8AddData, uint16_t u16Length ) { int32_t i32Ret = 0; if(NULL == ctx) { return (NULL_AEAD_CTX); } /* Initilaze GCM Context **/ mbedtls_gcm_init ( &(ctx->CtxAead) ); /*SETTING ADDITIONAL DATA as MD5 of incoming data **/ if( AEAD_AD_SIZE < u16Length ) { return (ERROR_INPUT_BUFFER_TOO_LONG); } memset( ctx->pu8AddData, 0x00, AEAD_AD_SIZE ); i32Ret = mbedtls_md5_ret(pu8AddData, u16Length, ctx->pu8AddData); if (i32Ret) { return (i32Ret); } /* symetric key for testing */ memset( ctx->pu8Key, 0xAB, AEAD_KEY_SIZE ) /* Setting the key */ if( i32Ret = mbedtls_gcm_setkey ( &(ctx->CtxAead), MBEDTLS_CIPHER_ID_AES, ctx->pu8Key, AEAD_KEY_SIZE*OCTETS ) ) { return (i32Ret); } while(1) { /* OS Wait for 1000ms for data to get ready */ if( OS_WaitSingleEventTimed( TX_DATA_BUFFER_READY, WAIT_1000MS ) ) { if( ctx->u16Length == 0 ) { /* No data ready for sending (or) timed-out */; continue; } /* New Initial Vector */ if( i32Ret = i32NewRandomByte( ctx->pu8InitVector, AEAD_IV_SIZE, "AEAD_NEW_IV_GENERATION" ) ) { return(i32Ret); } ctx->u16Length = u16Length; if( i32Ret = mbedtls_gcm_crypt_and_tag( &(ctx->CtxAead), MBEDTLS_GCM_ENCRYPT, ctx->u16Length, ctx->pu8InitVector, AEAD_IV_SIZE, ctx->pu8AddData, AEAD_AD_SIZE, ctx->pu8Data, ctx->pu8Cipher, AEAD_TAG_SIZE, ctx->pu8Tag)) { return(i32Ret); } if( ctx->u16Length == send_data(ctx->pu8Cipher, ctx->u16Length) ) { /* tx success*/ memset( ctx->pu8Data, 0x00, ctx->u16Length ); memset( ctx->pu8Cipher, 0x00, ctx->u16Length ); ctx->u16Length = 0; } } } /* Free GCM Context */ mbedtls_gcm_free( &(ctx->CtxAead) ); /* Reset context memory */ memset(ctx, 0, sizeof(S_Aead)); }

3 years

1
0
0 0

Re: mbed-tls Digest, Vol 26, Issue 5

by Christie Su

Hi, Is there anyone who can tell me how to send the question related to MbedTLS? Which forum can I sign in? Thanks, Christie -----Original Message----- From: mbed-tls-request(a)lists.trustedfirmware.org <mbed-tls-request(a)lists.trustedfirmware.org> Sent: April-25-22 8:00 PM To: mbed-tls(a)lists.trustedfirmware.org Subject: mbed-tls Digest, Vol 26, Issue 5 Send mbed-tls mailing list submissions to mbed-tls(a)lists.trustedfirmware.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to mbed-tls-request(a)lists.trustedfirmware.org You can reach the person managing the list at mbed-tls-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of mbed-tls digest..." Today's Topics: 1. misc. questions (Frank Bergmann) ---------------------------------------------------------------------- Message: 1 Date: Mon, 25 Apr 2022 12:47:07 +0200 From: Frank Bergmann <mbedtls(a)tuxad.com> Subject: [mbed-tls] misc. questions To: mbed-tls(a)lists.trustedfirmware.org Message-ID: <20220425104707.GA3579(a)treferpol.tuxad.net> Content-Type: text/plain; charset=us-ascii Hi all, I have some questions. 1) If you have an established TLS connection (mbed TLS 3.x) and while the connection is up the (server-) certificate expires: Will the connection stay up? Or is a new handshake (with valid cert) REQUIRED? 2) Related to question 1: CAN mbed TLS switch to a new cert on an existing TLS connection? (e.g. by doing another handshake from server OR client side) 3) With 3.x some struct members are now "private". Even if you can allow private access by a define it would be better to use a getter. But for ssl context's "state" I am missing this and also for "p_bio" (to access fd). Is there a chance to get this implemented? BTW - a big "LIKE" for 3.x! I really appreciate the changes. Thank you! kind regards, Frank ------------------------------ Subject: Digest Footer mbed-tls mailing list -- mbed-tls(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave(a)lists.trustedfirmware.org ------------------------------ End of mbed-tls Digest, Vol 26, Issue 5 ***************************************

3 years

1
0
0 0

2025

2024

2023

2022

2021

2020