- mbed-tls - lists.trustedfirmware.org

by François Beerten

Hi everyone, The PSA Crypto Driver Interface describes entry points for collecting entropy from drivers: |psa_status_t acme_get_entropy(uint32_t flags, size_t *estimate_bits, uint8_t *output, size_t output_size);| Currently, MbedTLS does not have any kind of support for those PSA driver entry points. I'm currently looking at trying to add initial support for those in the code. The idea is to write a very simple solution to get the ball rolling and that can be extended and improved later on. Is there interest for a patch to add this? There are different ways to integrate it into the current MbedTLS code. Do you already have plans or ideas on how it should be done? After multiple attempts locally, I've came up with an approach that can work well. Like for other PSA Crypto drivers, the entropy entry points would be listed in the generated "psa_crypto_driver_wrappers.c" file. Those entry points can then be used by a sub-function of mbedtls_entropy_gather(). What do you think of that approach? Best regards, François.

4 years, 6 months

2
1
0 0

Re: License conflict with OpenVPN

by Dave Rodgman

Hi Max, Unfortunately, it would not be possible for us to re-license the project to GPLv2 - this would require agreement with all copyright holders of code contributed to Mbed TLS 2.17, which isn't feasible. For this reason I'm afraid we cannot offer an exception for individual projects. Regards Dave Rodgman On 13/01/2022, 10:28, "Maximilian Fillinger via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org> wrote: Hello! OpenVPN can be compiled with OpenSSL or mbedtls. However, OpenVPN is licensed under GPLv2 only. If I understand correctly, that means it is not legal to distribute binaries of OpenVPN that are linked with mbedtls 2.17 or later. At Fox Crypto, we produce a hardened version of OpenVPN, called OpenVPN-NL, for use by the Dutch government, which uses mbedtls. (The latest release is rather old and still uses 2.16.) Is there anyone I could ask about making an exception for linking OpenVPN with mbedtls? Regards, Max Fillinger -- mbed-tls mailing list -- mbed-tls(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave(a)lists.trustedfirmware.org

4 years, 6 months

1
0
0 0

Invitation: MBed TLS Technical Forum - Asia @ Every 4 weeks from 3am to 3:50am on Monday 17 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 3am to 3:50am on Monday 17 times Mountain Standard Time - Phoenix Joining info: Join with Google Meet https://meet.google.com/fwh-srqw-rgf?hs=224 Join by phone (US) +1 304-397-0314 (PIN: 358348986) More phone numbers: https://tel.meet/fwh-srqw-rgf?pin=6539665554630&hs=0 Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin - creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org 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 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

4 years, 6 months

1
0
0 0

Invitation: MBed TLS Technical Forum @ Every 4 weeks from 9:30am to 10:30am on Monday 17 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 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 When: Every 4 weeks from 9:30am to 10:30am on Monday 17 times Mountain Standard Time - Phoenix Joining info: Join with Google Meet https://meet.google.com/ofy-jxph-boy?hs=224 Join by phone (US) +1 704-705-7047 (PIN: 141276187) More phone numbers: https://tel.meet/ofy-jxph-boy?pin=3695767709143&hs=0 Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin - creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWdhMWpuZ2ZpdWNp… 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

4 years, 6 months

1
0
0 0

Adding lists to the MBed TLS Tech Forum invite

by Don Harbin

Hi All, FYI, per Shebu, I'm adding both mbed-tls(a)lists.trustedfirmware.org and psa-crypto(a)lists.trustedfirmware.org to the MBed TLS Tech Forum invites. Please look for this in your inbox and accept it if you would like the series added to your calendar. - Note that this is a monthly meeting but you will see two invites, one that is for Asia timezones and one for Europe/US. Just delete the series that isn't timezone friendly for you. - FYI, recall that this and other tech forums can be found in the meeting calendar on the TF website <https://www.trustedfirmware.org/meetings/>. If you see a meeting in that calendar, click on the entry and an option comes up saying "copy to my calendar." It will import that single instance into your personal calendar from there if you wish. I wasn't able to test this feature with outlook, but it worked fine for google calendar. Please let me know if you have any questions. Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

4 years, 6 months

1
0
0 0

License conflict with OpenVPN

by Maximilian Fillinger

Hello! OpenVPN can be compiled with OpenSSL or mbedtls. However, OpenVPN is licensed under GPLv2 only. If I understand correctly, that means it is not legal to distribute binaries of OpenVPN that are linked with mbedtls 2.17 or later. At Fox Crypto, we produce a hardened version of OpenVPN, called OpenVPN-NL, for use by the Dutch government, which uses mbedtls. (The latest release is rather old and still uses 2.16.) Is there anyone I could ask about making an exception for linking OpenVPN with mbedtls? Regards, Max Fillinger

4 years, 6 months

1
0
0 0

Tinycrypt performance & integration

by andrei.menzopol＠nxp.com

Hello, I want to test/analyze the performance increase of using tinycrypt for ECC operations instead of the standard MbedTLS ECC functions. Could you please help me with a few answers regarding this? I am aware that tinycrypt is already integrated in the baremetal branch. Do you happen to know what is the performance increase of using this tinycrypt uECC implementation instead of the standard one on arm cortex m4 microcontrollers? I would like to port the tinycrypt uECC changes from baremetal branch to a Mbed TLS 2.25.0 version used in Matter repo (from where Mbed TLS repo is refered), more exactly this commit: https://github.com/ARMmbed/mbedtls/tree/1c54b5410fd48d6bcada97e30cac417c5c7… What do you think is the best approach? I thought of forking Mbed TLS, creating a separate branch with that commit and adding there the tinycrypt changes from baremetal branch. However, I'm not sure how to proceed next since the Matter repo refers the MbedTLS repo. Is this approach ok? Thank you!

4 years, 6 months

1
0
0 0

EC and FF checks support

by Thomas Fossati

Hi all, Does mbedTLS implement any of the checks in NIST SP 800 56Ar3? (In particular, I am interested in those defined in Section 5.6.2 [1]?) Thanks, cheers! [1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf…

4 years, 6 months

1
0
0 0

request to unsubscribe from this mailing list

by Innocenti, Michele

Hi, I have completed my job on these topics so I would like to unsubscribe from this mailing list, can you help me? Thank you! Michele [cid:image001.png@01D7FCCB.D711FD40] Hillrom is now a part of Baxter Michele Innocenti Sr Principal Engineer, SW Eng Gambro Dasco S.p.A. Via Modenese 66 / 41036 Medolla, Modena, Italy T. +39 0535.50578 michele_innocenti(a)baxter.com<mailto:michele_innocenti@baxter.com>

4 years, 6 months

3
2
0 0

Side by side installation of mbedtls 2.x and mbedtls 3.x

by Fabrice Fontaine

Dear all, mbedtls 3.x is incompatible with mbedtls 2.x so the transition of all the packages using mbedtls will take a long time. However, from my understanding, it is not possible to install both versions side by side as a lot of headers are common to both versions and installed in include/mbedtls. This fact is raising concern on buildroot side, see: https://patchwork.ozlabs.org/project/buildroot/patch/20211228153345.4087026… Can you confirm that a side-by-side installation of both mbedtls versions is not possible and/or can you share some inputs on this topic? Best Regards, Fabrice

4 years, 6 months

2
1
0 0

Mbed TLS releases: 2.16.12, 2.28.0, 3.1.0

by Dave Rodgman

Hi, We are pleased to announce the release of Mbed TLS 2.16.12, 2.28.0 and 3.1.0. These releases of Mbed TLS address several security issues, provide bug fixes, and new features, including initial support for TLS 1.3 in Mbed TLS 3.1.0. Full details are available in the release notes (https://github.com/ARMmbed/mbedtls/releases/tag/v3.1.0, https://github.com/ARMmbed/mbedtls/releases/tag/v2.28.0, https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.12). Mbed TLS 2.16.12 will be the last release in the 2.16 LTS; it will no longer be supported. Mbed TLS 2.28 is the new long-term support release, and will be supported with bug-fixes and security fixes until end of 2024. We recommend all users to consider whether they are impacted, and to upgrade appropriately. Dave Rodgman

4 years, 7 months

1
0
0 0

Commercial Support Request

by Felix Knorr

Dear MBedTLS-Team, we are currently evaluating MBedTLS for use in our Product. We develop an implant for blood pressure patients, and our implant and its charger need to communicate securely. We already have an AES encrypted communication running, but so far we just store the password in every device, and we would like to switch to RSA to exchange an AES key. It would also be important for us to be able to validate an x509 certificate on the implant. However, due to energy constraints, our internal flash memory on the implant is extremely small, and we would like to not parse the certificate on the implant, but rather send only the key and the signature directly, and then "validate by hand" on the implant. If I understand the procedure correctly, that would only involve taking a hash of the pubkey, decrypting the signature with a stored CA-public key, and compare them, correct? Would that be possible? Besides normal support during our implementation phase, we would be interested in being informed whenever a vulnerability is found in MBedTLS and a fast update. Do you offer such a service? If so, what will it cost? Kind Rergards, Felix Knorr -- Mit freundlichen Grüßen neuroloop GmbH i.A. Felix Knorr Senior Software Developer -------------------------------------- neuroloop GmbH Engesserstr. 4, 79108 Freiburg, Germany Amtsgericht Freiburg HRB 713935 Geschäftsführer: Dr. Michael Lauk, Dr. Dennis Plachta The information contained in this communication is confidential, may be attorney-client privileged, may constitute inside information, and is intended only for the use of the addressee. It is the property of the company of the sender of this e-mail. Unauthorized use, disclosure, or copying of this communication or any part thereof is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by return e-mail and destroy this communication and all copies thereof, including all attachments.

4 years, 7 months

2
1
0 0

mbedtls communication issue - handshake error -0x50 - NET - Connection was reset by pee

by Alugoju, Shailaja

Hi, I am trying to encrypt data on my rabbitmq communication. On the rabbitmq server end I am using the openssl and on the client end I cant use openssl but I can use mbedtls. I am using mbedtls-2.26.0 version in my rabbimq-c client . The certificate is generated via https://github.com/michaelklishin/tls-gen The certificate is valid and has no issue because the communication works fine when I use the ssl_client2 and ssl_server2 applications from the mbedtls-2.26.0\programs. The communication works fine when I use the rabbitmq openssl client and openssl server. But when I try to use the rabbitmq openssl server and ssl_client2 from mbedtls-2.26.0\programs the connection is reset. I think it’s a config issue but I am not able to figure out the solution or the rootcause. I am not sure if I can use mbedtls client with openssl server. Could you please help me in this. Below is the log from wireshark. Attached is the log from sslclient2 program. After the certificate is verified the broker resets the connection TCP 60271 → 5671 [SYN] Seq=0 Win=65535 Len=0 MSS=65475 WS=256 SACK_PERM=1 TCP 5671 → 60271 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=65475 WS=256 SACK_PERM=1 TCP 60271 → 5671 [ACK] Seq=1 Ack=1 Win=2618880 Len=0 TLSv1.2 Client Hello TCP 5671 → 60271 [ACK] Seq=1 Ack=305 Win=2618880 Len=0 TLSv1.2 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done TCP 60271 → 5671 [ACK] Seq=305 Ack=1976 Win=2616832 Len=0 TLSv1.2 Certificate TCP 5671 → 60271 [ACK] Seq=1976 Ack=945 Win=2618112 Len=0 TLSv1.2 Client Key Exchange TCP 5671 → 60271 [ACK] Seq=1976 Ack=1088 Win=2618112 Len=0 TLSv1.2 Certificate Verify TCP 5671 → 60271 [ACK] Seq=1976 Ack=1173 Win=2618112 Len=0 TLSv1.2 Change Cipher Spec TCP 5671 → 60271 [ACK] Seq=1976 Ack=1179 Win=2618112 Len=0 TLSv1.2 Encrypted Handshake Message TCP 5671 → 60271 [ACK] Seq=1976 Ack=1216 Win=2617856 Len=0 TLSv1.2 Change Cipher Spec, Encrypted Handshake Message TCP 60271 → 5671 [ACK] Seq=1216 Ack=2019 Win=2616832 Len=0 TLSv1.2 Application Data TCP 5671 → 60271 [ACK] Seq=2019 Ack=1245 Win=2617856 Len=0 TLSv1.2 Application Data TCP 60271 → 5671 [ACK] Seq=1245 Ack=2048 Win=2616832 Len=0 TLSv1.2 Encrypted Alert TCP 60271 → 5671 [ACK] Seq=1245 Ack=2071 Win=2616832 Len=0 TCP 5671 → 60271 [RST, ACK] Seq=2071 Ack=1245 Win=0 Len=0 Thanks, Shailaja

4 years, 7 months

1
0
0 0

Mbed TLS Tech Forum

by Dave Rodgman

Hi, On Monday at 10am UK time, we will hold the Mbed TLS Tech Forum. This is an open forum conference call for anyone to participate; please reply here if there are any agenda topics you would like to raise. Zoom details are in the TF calendar: https://www.trustedfirmware.org/meetings/mbed-tls-technical-forum/ or see below Dave 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

4 years, 7 months

3
4
0 0

Help troubleshooting mbedtls_pk_sign() returned -17280 (-0x4380)

by Martin Man

Hi guys, I have a mbetls based server client application (DTLS) written in Apple Swift language, wrapping the mbedtls C api, running just fine for many years now on iOS, Android, and Linux. We have been compiling the code with Swift 5.0, 5.1, 5.2, 5.3, 5.4 in both release and debug mode. Recently I just recompiled my code with Swift 5.5 in release mode, and my handshakes started failing on the Linux server with cryptic mbedtls_pk_sign() returned -17280 (-0x4380). When I take the same code and recompile in debug mode (-Onone) it works as expected. The same code compiled with Swift+C for iOS and macOS still works in both debug and release mode on both client/server. If I understand the compilation process correctly, the Swift Package Manager that we use to wrap mbedtls simply uses CMakeLists.txt to compile mbedtls and pick up the right flags. I am attaching excerpt from the log where the server part of the handshake fails (in release mode) and succeeds (in debug mode). I am certain this is probably caused by my code and how I wrap C mbedtls sources in Swift, but I can not yet rule out a bug in Swift/C compiler part for Linux which from time to time does have bugs related to code optimization. Could any good soul who understands the parts of the code below point me in the direction where to look and why would the mbedtls_pk_sign fail this way? What parts of the SSL context does it use? I will deep dive into the code to see whether this can be caused by memory corruption or anything else. It’s on LTS mbedtls-2.16.11. Could I run some tests to perhaps verify that mbedtls is compiled and working correctly? thanks for any help, Martin — failing handshake — Dec 7 15:54:53 ssl_srv.c:3296 => write server key exchange Dec 7 15:54:53 ssl_srv.c:3074 ECDHE curve: secp521r1 Dec 7 15:54:53 ssl_srv.c:3100 value of 'ECDH: Q(X)' (521 bits) is: Dec 7 15:54:53 ssl_srv.c:3100 01 d0 5f 4a fa 12 f8 46 75 fb 3e 38 db ba 88 ff Dec 7 15:54:53 ssl_srv.c:3100 73 72 79 78 21 dd 9f ac ac 02 db e7 7e 91 6e 5c Dec 7 15:54:53 ssl_srv.c:3100 06 ed 77 19 42 f1 11 6a f5 75 04 20 d8 51 50 a5 Dec 7 15:54:53 ssl_srv.c:3100 8f 5a 3d 8c b3 c0 15 df cc d7 5b e5 eb 04 2e b6 Dec 7 15:54:53 ssl_srv.c:3100 2f e7 Dec 7 15:54:53 ssl_srv.c:3100 value of 'ECDH: Q(Y)' (518 bits) is: Dec 7 15:54:53 ssl_srv.c:3100 26 c1 52 f0 b6 20 4c aa 53 7c aa 27 12 5f 72 7f Dec 7 15:54:53 ssl_srv.c:3100 11 ea a9 34 9a f5 ef 63 28 76 d8 52 4e 31 a3 13 Dec 7 15:54:53 ssl_srv.c:3100 52 a5 c9 52 5f 6b 41 b6 7e 47 0e 2a 68 c5 e5 80 Dec 7 15:54:53 ssl_srv.c:3100 14 27 ad aa 96 5b 89 41 55 5b d5 52 61 66 8c 06 Dec 7 15:54:53 ssl_srv.c:3100 4b Dec 7 15:54:53 ssl_srv.c:3163 pick hash algorithm 8 for signing Dec 7 15:54:53 ssl_srv.c:3201 dumping 'parameters hash' (64 bytes) Dec 7 15:54:53 ssl_srv.c:3201 0000: 55 c8 d2 5c 83 d8 6b e3 9f 9c b2 f4 e7 f7 4d 26 U..\..k.......M& Dec 7 15:54:53 ssl_srv.c:3201 0010: b4 ce c9 df c2 ae 7a 60 cb e8 02 13 d5 6d d8 ec ......z`.....m.. Dec 7 15:54:53 ssl_srv.c:3201 0020: 48 72 77 9f e2 69 4e f5 b4 1d db 9a 75 2a 5e c7 Hrw..iN.....u*^. Dec 7 15:54:53 ssl_srv.c:3201 0030: e1 1b 66 fc a6 ff 37 c6 6d 42 9b b3 cf 63 bb 0e ..f...7.mB...c.. Dec 7 15:54:53 ssl_srv.c:3274 mbedtls_pk_sign() returned -17280 (-0x4380) Dec 7 15:54:53 ssl_tls.c:8219 <= handshake — successful handshake — Dec 7 16:13:52 ssl_srv.c:3296 => write server key exchange Dec 7 16:13:52 ssl_srv.c:3074 ECDHE curve: secp521r1 Dec 7 16:13:52 ssl_srv.c:3100 value of 'ECDH: Q(X)' (519 bits) is: Dec 7 16:13:52 ssl_srv.c:3100 52 5f 4e 78 48 bd be 6a e4 98 21 30 ce 1c ba 08 Dec 7 16:13:52 ssl_srv.c:3100 b7 ae 88 d3 ff c9 c4 a5 8c 13 1e 73 5b 1f 08 60 Dec 7 16:13:52 ssl_srv.c:3100 7c 51 a7 ec 91 54 d7 52 f3 55 6a 34 92 cf 92 e8 Dec 7 16:13:52 ssl_srv.c:3100 c8 39 33 5e d3 46 3d 89 e7 6d 8f 41 d9 e0 67 e6 Dec 7 16:13:52 ssl_srv.c:3100 7c Dec 7 16:13:52 ssl_srv.c:3100 value of 'ECDH: Q(Y)' (520 bits) is: Dec 7 16:13:52 ssl_srv.c:3100 87 48 29 20 93 8e f8 9a a9 54 70 26 58 79 9d 67 Dec 7 16:13:52 ssl_srv.c:3100 8c ec 0f 06 ae 73 13 40 72 58 fe c1 6e 14 b4 48 Dec 7 16:13:52 ssl_srv.c:3100 55 a1 27 74 9d 63 36 aa db 80 29 f8 ab 9c 64 ba Dec 7 16:13:52 ssl_srv.c:3100 f9 0a 19 af 9a 65 6f 02 96 c6 53 4d 49 4f b4 f5 Dec 7 16:13:52 ssl_srv.c:3100 46 Dec 7 16:13:52 ssl_srv.c:3163 pick hash algorithm 8 for signing Dec 7 16:13:52 ssl_srv.c:3201 dumping 'parameters hash' (64 bytes) Dec 7 16:13:52 ssl_srv.c:3201 0000: e1 65 f4 f0 a6 a3 67 7d 32 55 ed 2a 13 08 71 8a .e....g}2U.*..q. Dec 7 16:13:52 ssl_srv.c:3201 0010: 7e 13 f6 30 85 ed c3 c9 10 e8 b2 43 75 bc 6c 24 ~..0.......Cu.l$ Dec 7 16:13:52 ssl_srv.c:3201 0020: 8f fb d8 90 cb 53 7f 13 53 13 1b f4 eb bd 38 5c .....S..S.....8\ Dec 7 16:13:52 ssl_srv.c:3201 0030: ec 46 c2 0c a9 93 5b 60 5e 5d 81 f2 b3 b0 b5 a8 .F....[`^]...... Dec 7 16:13:52 ssl_srv.c:3361 dumping 'my signature' (256 bytes) Dec 7 16:13:52 ssl_srv.c:3361 0000: 7a a7 0f 17 79 33 36 b7 0c 17 84 5b cc ca 1c 0c z...y36....[.... Dec 7 16:13:52 ssl_srv.c:3361 0010: cb f5 56 80 ea 5d 7f cf ab 86 d5 f9 91 36 0e 68 ..V..].......6.h Dec 7 16:13:52 ssl_srv.c:3361 0020: 76 c6 c0 4b 77 bf 28 e7 b8 c0 a7 de ea d8 a0 30 v..Kw.(........0 Dec 7 16:13:52 ssl_srv.c:3361 0030: 3a b3 4e 24 ea e0 c8 0b e7 ad ba 4d 35 30 c0 39 :.N$.......M50.9 Dec 7 16:13:52 ssl_srv.c:3361 0040: a8 ff f0 6d 8f 28 db fc 5e c3 fb 21 fe 76 dd 07 ...m.(..^..!.v.. Dec 7 16:13:52 ssl_srv.c:3361 0050: 1b 2c 58 fe 7b 0a f5 72 49 d9 d1 9a 10 af 29 21 .,X.{..rI.....)! Dec 7 16:13:52 ssl_srv.c:3361 0060: 7a d9 01 a4 99 01 de 6e ae fd 76 ce b9 64 84 49 z......n..v..d.I Dec 7 16:13:52 ssl_srv.c:3361 0070: 96 97 2d 3a 15 ed 5b de d5 99 9d 1b eb 4c 1a aa ..-:..[......L.. Dec 7 16:13:52 ssl_srv.c:3361 0080: a8 e6 36 29 bd 67 b0 50 91 6e b8 cb 0a 42 4a 79 ..6).g.P.n...BJy Dec 7 16:13:52 ssl_srv.c:3361 0090: 4a 65 ae 95 d0 bc 5a e1 e7 75 2a f9 ba 51 1c 2c Je....Z..u*..Q., Dec 7 16:13:52 ssl_srv.c:3361 00a0: ff 67 e3 df eb a0 d7 6c d2 cf 71 d2 ea 24 7c 16 .g.....l..q..$|. Dec 7 16:13:52 ssl_srv.c:3361 00b0: f8 5b 72 83 56 a9 48 e1 b6 cd d0 bd dd 20 23 d5 .[r.V.H...... #. Dec 7 16:13:52 ssl_srv.c:3361 00c0: 80 c4 bd 6e 42 1c 61 b2 e4 41 01 ce c8 85 26 21 ...nB.a..A....&! Dec 7 16:13:52 ssl_srv.c:3361 00d0: b4 0a 5e fe 50 0d 6f 45 a8 fe 15 18 87 e3 ae b3 ..^.P.oE........ Dec 7 16:13:52 ssl_srv.c:3361 00e0: ac 46 c5 c6 bb bc 70 1b 32 b7 15 c5 3d fb 09 1e .F....p.2...=... Dec 7 16:13:52 ssl_srv.c:3361 00f0: 8f 69 f7 e7 a8 86 4d 0b 87 ea 4b fe 08 7e 00 0b .i....M...K..~.. Dec 7 16:13:52 ssl_tls.c:3289 => write handshake message Dec 7 16:13:52 ssl_tls.c:2917 => ssl_flight_append Dec 7 16:13:52 ssl_tls.c:2953 <= ssl_flight_append Dec 7 16:13:52 ssl_tls.c:3425 <= write handshake message Dec 7 16:13:52 ssl_srv.c:3380 <= write server key exchange

4 years, 7 months

2
2
0 0

Benchmark on esp32

by Marco Portoni

Hi, Is it possible to run the benchmark of all cyphers natively on a ESP32 board? I have already run them on laptop but my goal is to run them on esp32, using for example tool like espifd.

4 years, 7 months

1
0
0 0

lists.trustedfirmware.org

by Philip Colmer

Hello You are receiving this email because you are subscribed to one or more mailing lists on lists.trustedfirmware.org. The purpose of this email is to let you know that the software on the server is being upgraded between Wednesday 29th December and Friday 31st December. During that time, the server will be unavailable and any email sent to a list on the server will be queued for later delivery. After the upgrade has been completed, you will receive a follow-up email from me to confirm that the upgrade has been completed and to provide you with instructions on how to set up your account on the new server. With the new software, you have one account regardless of how many mailing lists you are subscribed to. Regards Philip Colmer Director, Information Services Linaro

4 years, 7 months

1
0
0 0

Output a mbedtls_x509_crt?

by Felipe Gasper

Hello, Is it possible to output a mbedtls_x509_crt as PEM or DER? I’ve been combing the API docs but don’t see how I can do this export. I see controls for exporting a newly-built cert, but not one that comes from, e.g., mbedtls_ssl_get_peer_cert(). Thank you! Cheers, -Felipe Gasper

4 years, 7 months

2
3
0 0

What am I doing wrong?

by Felipe Gasper

https://gist.github.com/FGasper/43758d13e987518009d18ec8951ffcbb ^^ With 3.0.0 this prints: seeded entropy mbedtls connected trust loaded ok SNI set ok handshake tried handshake: X509 - Certificate verification failed, e.g. CRL, CA or signature check failed … but if I switch to the development branch, it works. Same trust chain, same code … but the production code fails while the dev one works … Am I just “holding it wrong”? Thank you in advance! -FG

4 years, 7 months

1
1
0 0

MbedTLS - which protocols are advisable to support, and memory usage

by Peter

Hi All, I am new here. With a colleague, I am working on a product which previously used PolarSSL but was later changed to MbedTLS which, in the ST ARM 32F417 implementation, is believed to be less buggy. It is working ok as far as we have got, but we are finding that as well as needing some 100k more FLASH, it needs nearly 50k of RAM, which on the 32F417 (128k RAM) would normally be OK but due to other required functionality it leaves us just 10k. The architecture we are using for MbedTLS is a 48k (48k was found to be the smallest that works) static buffer within which TLS runs its own heap. I am aware that in the most generic case one has to have enough for one 16k buffer (plus a bit) for HTTPS, but what concerns me is that there appears to be no way to determine the worst case memory usage, across various usage scenarios. It would also be great to reduce this 48k to say 30k. Some of the protocols we know we don't need (e.g. PPP) but within any of them there is the question of which cipher suite needs supporting. What is the minimum cipher suite required to be able to use MbedTLS as an HTTPS client for use with typical current cloud-based file storage or data logging APIs such as Dropbox, Google Drive, Loggly etc? And what is the recommended minimum cipher suite required to implement an HTTPS server that would be able to negotiate a session with most current web-browsers? The goal is to ideally reduce both RAM and code size requirements for use in an embedded device that needs to work both as a general purpose server and client, without requiring support for multiple concurrent sessions. The other thing is that even the ST port of MbedTLS doesn't appear to make use of ST CPU hardware features such as AES256, DES, etc, which the 32F417 has in hardware. This speeds things up hugely but much more importantly in our case, saves a lot of RAM. For example AES256 can use about 10k if done in software. Thank you very much in advance for any input on what can be done. Peter

4 years, 7 months

1
0
0 0

Question about a research project: ESP32 mbed-tls

by Marco Portoni

Hello, I am Marco Portoni and I am working on a thesis research for the University of Study of Milan. It is focused on cryptographic libraries in the IoT world, and my question is: is it possible to run the benchmark on a ESP32? I have already runned the benchmark on 2 of my laptops to test and collected the results, but my ultimate goal is to make the benchmark run on the ESP. Is it possible to do it? Thanks for every help! Marco

4 years, 7 months

1
0
0 0

Build shared on macOS?

by Felipe Gasper

Hello, I’m trying to build shared from git on macOS and having no luck. I’m doing: > mkdir build; cd build > cmake DUSE_SHARED_MBEDTLS_LIBRARY=On .. … > make … > ls -la library total 2944 drwxr-xr-x 10 felipe staff 320 Dec 1 08:49 . drwxr-xr-x 15 felipe staff 480 Dec 1 08:49 .. drwxr-xr-x 8 felipe staff 256 Dec 1 08:49 CMakeFiles -rw-r--r-- 1 felipe staff 92755 Dec 1 08:49 Makefile -rw-r--r-- 1 felipe staff 2942 Dec 1 08:49 cmake_install.cmake -rw-r--r-- 1 felipe staff 34055 Dec 1 08:49 error.c -rw-r--r-- 1 felipe staff 916112 Dec 1 08:49 libmbedcrypto.a -rw-r--r-- 1 felipe staff 315856 Dec 1 08:49 libmbedtls.a -rw-r--r-- 1 felipe staff 104072 Dec 1 08:49 libmbedx509.a -rw-r--r-- 1 felipe staff 26265 Dec 1 08:49 version_features.c Am I just missing something? It seems like I’m following what the README says to do; I also did `export SHARED=1` just in case, but that made no difference. Thank you in advance! -FG

4 years, 7 months

3
3
0 0

Re: [mbed-tls] End of Life of LTS branch 2.16

by Dave Rodgman

Hi Radhika, We do not plan to extend support for Mbed TLS 2.16 beyond the three year support period. We do plan to release a 2.x LTS (probably 2.28) alongside the final 2.16 release, so that we always have an LTS available. Regards Dave Rodgman From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Radhika Jandhyala via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: Radhika Jandhyala <radhikaj(a)microsoft.com> Date: Monday, 22 November 2021 at 10:50 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] End of Life of LTS branch 2.16 Hi, I am a maintainer for https://github.com/openenclave/openenclave. We include mbedtls 2.16 as a submodule in our project. Reading the article below, it states that 2.16 support will last at least till Dec 2021. Will you continue to support 2.16 in 2022? https://tls.mbed.org/tech-updates/blog/announcing-lts-branch-mbedtls-2.16 We are specifically interested in CVE fixes being backported to 2.16 and the timeframe where that will continue. Is there an updated timeline for this? We do plan to upgrade to 3.0 in early 2022, but we anticipate that will take some effort due to breaking changes. Thank you very much! Radhika

4 years, 8 months

2
2
0 0

Mbed TLS long term support release plans

by Dave Rodgman

Hi, Mbed TLS 2.16 LTS is approaching the end of its support period – it was originally announced that it would be maintained for at least 3 years up until the end of 2021 – and currently there is no other LTS branch. To ensure that there is no period of time without a supported LTS branch, we plan to release 2.28 LTS in the near future (which will have the usual 3 year support period). We will continue supporting 2.16 LTS until this is available. The expectation is that as 2.28 will be API-compatible with 2.16, users of 2.16 LTS will be able to upgrade to 2.28 very easily. Progress towards 2.28 LTS can be followed here: https://github.com/orgs/ARMmbed/projects/18#column-15836286 Dave Rodgman

4 years, 8 months

1
0
0 0

End of Life of LTS branch 2.16

by Radhika Jandhyala

Hi, I am a maintainer for https://github.com/openenclave/openenclave. We include mbedtls 2.16 as a submodule in our project. Reading the article below, it states that 2.16 support will last at least till Dec 2021. Will you continue to support 2.16 in 2022? https://tls.mbed.org/tech-updates/blog/announcing-lts-branch-mbedtls-2.16 We are specifically interested in CVE fixes being backported to 2.16 and the timeframe where that will continue. Is there an updated timeline for this? We do plan to upgrade to 3.0 in early 2022, but we anticipate that will take some effort due to breaking changes. Thank you very much! Radhika

4 years, 8 months

1
0
0 0

PSA Crypto non-optional in Mbed TLS 3.1

by Manuel Pegourie-Gonnard

Hi, We'd like to announce a change we intend to make: starting with Mbed TLS 3.1, it will no longer be possible to build with TLS, X.509, or PK without support for PSA Crypto. Details: currently, use of PSA Crypto APIs from the TLS, X.509 and PK layers is controlled by the option MBEDTLS_USE_PSA_CRYPTO. When this option is disabled (which is the default), it's possible to build without MBEDTLS_PSA_CRYPTO_C. Starting with 3.1, we intend to start making TLS, X.509 and PK use PSA Crypto unconditionally, so MBEDTLS_PSA_CRYPTO_C will be automatically enabled in the build as soon as TLS, X.509 or PK is enabled. Impact: for users who already build with PSA Crypto enabled (the default), no impact. For users who currently disable MBEDTLS_PSA_CRYPTO_C in their configuration, starting with 3.1 there will be no functional changes, but the size of the built library will increase due to the additional features enabled. The increase depends on the configuration, application, platform, and toolchain, but the order of magnitude currently ranges from about 9 KB for a minimal TLS configuration with LTO (link-time optimisation) to about 30 KB for a full configuration without link-time garbage collection (though size-constrained devices are very unlikely to use such a configuration); we aim to reduce this overhead in the future. Rationale: maintaining two versions of every cryptographic operation in upper layers (one PSA, one non-PSA) imposes a significant burden on new developments. By removing that burden, we hope to progress faster on things that are more important in the long run, including better integration of PSA Crypto in TLS and X.509, and future code size optimisation of PSA Crypto. We realise the impact on users who were excluding PSA Crypto is significant. We're going to release Mbed TLS 2.28 in the coming months, which is not affected by this change and will receive bug fixes and security fixes for at least 3 years; we hope it provides an acceptable fall-back solution to affected users. In the long run, PSA Crypto will become the only Crypto API we offer; we want to make its footprint as small as possible considering its feature set and we hope this change will enable us to make faster progress towards that goal. Best regards, Manuel Pégourié-Gonnard for the Mbed TLS team.

4 years, 8 months

1
0
0 0

About `MBEDTLS_ALLOW_PRIVATE_ACCESS`

by Aditya Patwardhan

Hi, While working on updating mbedtls to v3.0, I saw that the internal fields in MBEDTLS have been made private. ( ref- here<https://github.com/ARMmbed/mbedtls/blob/development/docs/3.0-migration-guid…>). It says there and I quote "As a last resort, you can access the field foo of a structure bar by writing bar.MBEDTLS_PRIVATE(foo). Note that you do so at your own risk, since such code is likely to break in a future minor version of Mbed TLS.” I just wanted to know if there is any alternative solution to this, rather than using `MBEDTLS_PRIVATE` everywhere. I know the next release of mbedtls probably plans to fix this with appropriate solution. But we wanted to push out our feature branch As early as possible. I saw in the PR<https://github.com/zephyrproject-rtos/zephyr/pull/37753> in zephyr RTOS about updating to mbedtls-3.0. They have just added this line<https://github.com/ceolin/zephyr/blob/5bf3128a9703561e578651218f5bcdafb96f8…> #if !defined(MBEDTLS_ALLOW_PRIVATE_ACCESS) #define MBEDTLS_ALLOW_PRIVATE_ACCESS # endif Is this an alternative solution to using `MBEDTLS_PRIVATE` for accessing a private field. If yes, can somebody please point me to respective document as this would greatly reduce our code-changes. I understand there is some discussion going on in mbedtls about this change, and appropriate getter-setter functions shall be provided. But we wanted to push out out feature branch for early testing. Thanks and Regards, Aditya

4 years, 8 months

2
2
0 0

Mbed TLS Tech Forum

by Dave Rodgman

Hi, On Monday 8th we will have the next Mbed TLS Tech Forum. Please reply to the list if you have any agenda topics to raise. As a starter for the agenda, we will likely discuss: https://github.com/ARMmbed/mbedtls/pull/5067 Proposal for driver dispatch code gen Dave Rodgman Zoom details below. The call will be recorded and made available on the TF website : https://www.trustedfirmware.org/meetings/ 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

4 years, 8 months

1
0
0 0

mbedtls client: TLS 1.2 Client Hello triggers a -0x7780 fatal internal server error...?

by secretimap＠nickpelling.com

Hi everyone, The company I’m working for uses mbedtls to drive an embedded TLS server (for HTTPS): but now needs the same device to also act as a TLS client for logging in to remote servers (e.g. for LDAP etc). My embedded test code tries (but fails) to connect to a remote HTTPS server on port 443: I can connect to the same server via openssl on a desktop command line, so it seems to be working. Basically, the client hello message goes out fine (for brevity, I’ve skipped all the ciphersuites, but note that the list does contain the 0xC030 ciphersuite that desktop openssl is able to connect to OK): .ssl_cli.c:934: client hello, got 25 ciphersuites (excluding SCSVs) .ssl_cli.c:943: adding EMPTY_RENEGOTIATION_INFO_SCSV .ssl_cli.c:992: client hello, compress len.: 1 .ssl_cli.c:994: client hello, compress alg.: 0 .ssl_cli.c:186: client hello, adding signature_algorithms extension .ssl_cli.c:271: client hello, adding supported_elliptic_curves extension .ssl_cli.c:336: client hello, adding supported_point_formats extension .ssl_cli.c:518: client hello, adding encrypt_then_mac extension .ssl_cli.c:552: client hello, adding extended_master_secret extension .ssl_cli.c:585: client hello, adding session ticket extension .ssl_cli.c:1071: client hello, total extension length: 52 0000: 16 03 01 00 95 01 00 00 91 03 03 16 e9 7a ea aa 0010: 31 81 60 b6 a8 d3 32 93 a4 50 ca f3 e0 66 f8 47 0020: 56 95 0c cd a0 db b6 0e ae a7 d4 00 00 34 c0 30 0030: 00 9f c0 ad c0 9f c0 24 c0 28 00 6b c0 0a c0 14 0040: 00 39 c0 af c0 a3 c0 2b c0 2f 00 9e c0 ac c0 9e 0050: c0 23 c0 27 00 67 c0 09 c0 13 00 33 c0 ae c0 a2 0060: 00 ff 01 00 00 34 00 0d 00 16 00 14 06 03 06 01 0070: 05 03 05 01 04 03 04 01 03 03 03 01 02 03 02 01 0080: 00 0a 00 04 00 02 00 17 00 0b 00 02 01 00 00 16 0090: 00 00 00 17 00 00 00 23 00 00 However, the server hello that comes back is both unhappy and unhelpful: .ssl_tls.c:2721: in_left: 5, nb_want: 7 .ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 2 (-0xfffffffe) .ssl_tls.c:2742: <= fetch input .ssl_tls.c:4233: dumping 'input record from network' (7 bytes) .ssl_tls.c:4233: 0000: 15 03 03 00 02 02 50 ......P .ssl_tls.c:5170: got an alert message, type: [2:80] .ssl_tls.c:5178: is a fatal alert message (msg 80) .ssl_tls.c:4369: mbedtls_ssl_handle_message_type() returned -30592 (-0x7780) .ssl_cli.c:1506: mbedtls_ssl_read_record() returned -30592 (-0x7780) Putting the ciphersuites to one side, I suspect that what is happening here is that the (remote) server is complaining about a TLS extension the mbedtls client is either including or omitting. (I’ve already disabled the max fragment extension). But because I can’t see inside the remote server, I can’t tell. ☹ Might the mbedtls TLS client need the supported_versions extension (43) to work with many remote TLS servers? Is this a known issue? I’ve gone through loads of mailing list archive messages here, but haven’t found anything that matches this. Thanks, Nick PS: when OpenSSL connects to the server, the client hello message (that works fine) looks like this in Wireshark: Transport Layer Security TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 358 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 354 Version: TLS 1.2 (0x0303) Random: [SNIP] GMT Unix Time: Jan 21, 2095 20:50:07.000000000 GMT Standard Time Random Bytes: [SNIP] Session ID Length: 32 Session ID: [SNIP] Cipher Suites Length: 90 Cipher Suites (45 suites) [SNIP!] Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 191 Extension: status_request (len=5) Type: status_request (5) Length: 5 Certificate Status Type: OCSP (1) Responder ID list Length: 0 Request Extensions Length: 0 Extension: supported_groups (len=22) Type: supported_groups (10) Length: 22 Supported Groups List Length: 20 Supported Groups (10 groups) Supported Group: x25519 (0x001d) Supported Group: secp256r1 (0x0017) Supported Group: secp384r1 (0x0018) Supported Group: secp521r1 (0x0019) Supported Group: x448 (0x001e) Supported Group: ffdhe2048 (0x0100) Supported Group: ffdhe3072 (0x0101) Supported Group: ffdhe4096 (0x0102) Supported Group: ffdhe6144 (0x0103) Supported Group: ffdhe8192 (0x0104) Extension: ec_point_formats (len=2) Type: ec_point_formats (11) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) EC point format: uncompressed (0) Extension: signature_algorithms (len=34) Type: signature_algorithms (13) Length: 34 Signature Hash Algorithms Length: 32 Signature Hash Algorithms (16 algorithms) [SNIP!] Extension: signature_algorithms_cert (len=34) Type: signature_algorithms_cert (50) Length: 34 Signature Hash Algorithms Length: 32 Signature Hash Algorithms (16 algorithms) [SNIP!] Extension: status_request_v2 (len=9) Type: status_request_v2 (17) Length: 9 Certificate Status List Length: 7 Certificate Status Type: OCSP Multi (2) Certificate Status Length: 4 Responder ID list Length: 0 Request Extensions Length: 0 Extension: extended_master_secret (len=0) Type: extended_master_secret (23) Length: 0 Extension: supported_versions (len=5) Type: supported_versions (43) Length: 5 Supported Versions length: 4 Supported Version: TLS 1.3 (0x0304) Supported Version: TLS 1.2 (0x0303) Extension: psk_key_exchange_modes (len=2) Type: psk_key_exchange_modes (45) Length: 2 PSK Key Exchange Modes Length: 1 PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1) Extension: key_share (len=38) Type: key_share (51) Length: 38 Key Share extension Client Key Share Length: 36 Key Share Entry: Group: x25519, Key Exchange length: 32 Group: x25519 (29) Key Exchange Length: 32 Key Exchange: 9f8e83a6859e6b4c6c3e43b524b81e6f63cc409c5757692a2343a2929c681c17

4 years, 8 months

1
0
0 0

Compact public ECC key representation

by Hristozov, Stefan

Hi all, For an IETF protocol that I am currently implementing a compact representation [1] of ECDH public keys needs to be sent over the network and be used on the receiving side for deriving a shared secret. With psa_export_public_key() I can export the public key form a psa_key_id_t object. The exported key is 65 bytes long (I am working with P256) which has the format 04|x|y as documented in [2]. It is easy to compress the public key before sending it -> just send the x part. How to decompress the x part back to the representation 04|x|y. As far I understand the psa_raw_key_agreement() function the public key must be encoded "in the same format that psa_import_key() accepts", that is 04|x|y [3]. Is there a function for that? [1]: https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#appendix-B draft-ietf-lake-edhoc-12<https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#appendix-B> Network Working Group G. Selander Internet-Draft J. Preuß Mattsson Intended status: Standards Track F. Palombini Expires: 23 April 2022 Ericsson 20 October 2021 Ephemeral Diffie-Hellman Over COSE (EDHOC) draft-ietf-lake-edhoc-12 Abstract This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. datatracker.ietf.org [2]: https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b… [https://opengraph.githubassets.com/aee6bf8d395880d12a54b66dd4188b9fd92064a1…]<https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b…> mbedtls/crypto.h at f660c7c92308b6080f8ca97fa1739370d1b2fab5 · ARMmbed/mbedtls<https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b…> An open source, portable, easy to use, readable and flexible SSL library - mbedtls/crypto.h at f660c7c92308b6080f8ca97fa1739370d1b2fab5 · ARMmbed/mbedtls github.com [3]: https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b… [https://opengraph.githubassets.com/aee6bf8d395880d12a54b66dd4188b9fd92064a1…]<https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b…> mbedtls/crypto.h at f660c7c92308b6080f8ca97fa1739370d1b2fab5 · ARMmbed/mbedtls<https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b…> An open source, portable, easy to use, readable and flexible SSL library - mbedtls/crypto.h at f660c7c92308b6080f8ca97fa1739370d1b2fab5 · ARMmbed/mbedtls github.com Br, Stefan

4 years, 9 months

1
0
0 0

Using mbedtls with a CA chain

by Loren Rogers

I need to use mbedtls (bundled with Nordic SDK, and unsure of version) to do some cloud-based functionality (AWS cloud, using OpenAM with a CA chain containing 4 certs). According to something I read, I need to use a pkcs7 container? If so, it seems that mbedtls does not support pkcs7? I did hand-copy some code from a PR, but as I was looking through the pkcs7.c, it seems that it still only supports the CA Root. Is this true? Is there anyone that can give me a hand in solving what I am attempting to do? Thank you /Loren Rogers

4 years, 9 months

1
0
0 0

password for the files root.cer, client1.cer and client1-key.pem

by lekshmi g

Dear Sir,/Madam We need to convert the files - root.cer,client1.cer and client1-key.pem to jks using the tool keystore explorer. For that, the password for the files are needed.Please provide passwords.We need to establish connection between java client and mbedtls c server.Kindly provide help. Regards Lekshmi G

4 years, 9 months

1
0
0 0

TLS connection establishment between OpenMUC java client and mbedtls server

by lekshmi g

Dear Madam/Sir, We are working on a project which requires IEC 62351 standards. For that we had developed a TLS server in C language and we had the requirement of developing a TLS client in Java language. We had used the *mbedTLS library for server* and *OpenMUC libraries for client*. But we are getting exception while certificate exchange phase and all. We had attached the listed exceptions and errors. Kindly provide necessary support for the same. Also please confirm whether we can develop above specified architecture, ie TLS based server in C language and client in Java. If available please share some sample programs also. Please reply ASAP. We have debugged the code and the following are the messages we have got in mbedtls java server and OPENMUC java tls client . During certificate exchange from client to server (MBEDTLS_SSL_CLIENT_CERTIFICATE case in server), the function returns a nonzero value and the alert shows in server is 49 (ie, MBEDTLS_SSL_ALERT_MSG_ACCESS_DENIED). *Please check Fig 1 and Fig 2* for the messages displayed during connection establishment.Kindly help us to solve the issues. [image: image.png] Fig 1- case:MBEDTLS_SSL_CLIENT_CERTIFICATE fails [image: image.png] Fig 2-OPENMUC java client error when connecting to mbedtlsserver ReplyForward <https://drive.google.com/u/0/settings/storage?hl=en&utm_medium=web&utm_sour…> <https://www.google.com/intl/en/policies/terms/> <https://www.google.com/intl/en/policies/privacy/> <https://www.google.com/gmail/about/policy/>

4 years, 9 months

1
0
0 0

[Mbed-tls-announce] Mbed TLS Tech Forum

by Dave Rodgman via Mbed-tls-announce

Hi, I would like to announce the Mbed TLS Tech Forum, a regular engineering call to discuss topics of interest to the Mbed TLS community. The call is currently planned to take place every two weeks, alternating between US-friendly and China-friendly times (16:30 and 10:00 UK time), starting on the 25th October at 16:30 BST. Please reply to the list if you have any agenda topics to raise. As a starting point, we will cover: Format – check if times & cadence are suitable TLS 1.3 – high-level update on progress & direction PSA Cryptoprocessor Driver Interface – code generation for driver dispatch as per https://github.com/ARMmbed/mbedtls/pull/5067 Zoom details below. The call will be recorded and made available on the TF website: https://www.trustedfirmware.org/meetings/ Dave Rodgman Mbed TLS tech lead -- Dave Rodgman is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://armltd.zoom.us/j/93259847316?pwd=N0d4Z0o5RXRLKzZFaE1sd044bm14dz09&f… Meeting ID: 932 5984 7316 Passcode: 991642 One tap mobile +442034815240,,93259847316#,,,,*991642# United Kingdom Dial by your location +44 203 481 5240 United Kingdom +1 346 248 7799 US (Houston) +1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +91 116 480 2722 India +91 224 879 8012 India +91 406 480 2722 India +91 806 480 2722 India +852 5803 3730 Hong Kong SAR +46 8 4468 2488 Sweden +972 3 978 6688 Israel +353 1 536 9320 Ireland +36 1 408 8456 Hungary +33 1 7037 2246 France +358 3 4109 2129 Finland +45 32 70 12 06 Denmark +1 438 809 7799 Canada +65 3158 7288 Singapore +27 87 550 3946 South Africa +32 1579 5132 Belgium +48 22 307 3488 Poland +386 1600 3102 Slovenia +60 3 3099 2229 Malaysia +886 (2) 7741 7473 Taiwan Meeting ID: 932 5984 7316 Passcode: 991642 Find your local number: https://armltd.zoom.us/u/adTMafG7oQ Join by SIP 93259847316(a)zoomcrc.com Join by H.323 162.255.37.11 (US West) 162.255.36.11 (US East) 115.114.131.7 (India Mumbai) 115.114.115.7 (India Hyderabad) 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) 103.122.166.55 (Australia Sydney) 103.122.167.55 (Australia Melbourne) 209.9.211.110 (Hong Kong SAR) 149.137.40.110 (Singapore) 64.211.144.160 (Brazil) 69.174.57.160 (Canada Toronto) 65.39.152.160 (Canada Vancouver) 207.226.132.110 (Japan Tokyo) 149.137.24.110 (Japan Osaka) Meeting ID: 932 5984 7316 Passcode: 991642 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 https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce

4 years, 9 months

3
2
0 0

switching from libressl to MbedTLS

by LM

I'm hoping to make the switch from libressl to MbedTLS. I'm working on a Linux from scratch style project. Curl works fine with MbedTLS and most of the utilities I work with use libcurl. I'm also using libtomcrypt for some of its hash and cryptographic functionality. The only place I'm having a problem making the switch at present is when I follow the LFS logic to make certificates (make-ca). There's a openssl/libressl command in the script that looks like the following: openssl x509 -hash -noout -in "$1" Is there a way to replace this functionality with a command or procedure or function from another program so that libressl or openssl isn't needed to perform this step? Thanks.

4 years, 9 months

1
0
0 0

Mbedtls Client Key Exchange Time

by Duygu D.

Hello, I'm using mbedTLS on baremetal lwip+stm32f4 system as a Server. TLS working successfully with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 but when I receive the Client Hello message than my receive proccess function in ethernetif_input: err = netif->input(p, netif); takes 300ms time. This function normaly takes 1ms. I need to reduce this time. How Can I do that ? This is my config file: https://paste.ofcode.org/Bdt4FapskKY7M5ggm3uViJ Best Regards. -- Embeded System Engineer

4 years, 9 months

1
0
0 0

passing jks format client certificate

by lekshmi g

Dear Madam/Sir We need to establish connection with security between MMS client application in java(OPENMUC java client) and MMS server (tls_server_example in mbedtls).The java client application uses keystore.jks and truststore.jks (*jks format* ) instead of certificate in *cer *format.Is it possible to establish connection between OPENMUC java mms client and libiec61850 1.5 with mbedtls-2.16.6* ?* . We have added the *root.cer details *(certificate in the sample mbedtls server program ) to * truststore.jks* in client (openmuc java) and *client1.cer details* (client1 certificate in the sample mbedtls server program ) *to keystore.jks* .When trying to establish connection server hello messages are completed ,but showing the following error: *MBEDTLS_ERR_SSL_NO_CLIENT_CERTIFICATE.* * Please help...* *Regards* *Lekshmi G*

4 years, 9 months

1
0
0 0

Re: [mbed-tls] [TF-M] Adding platform specific functions to Crypto Service.

by Fabian Schmidt

Hi Roman, My understanding is that you would like to add features to the Crypto service API, but the features which you would like to add are not cryptographic in nature. Have you considered creating your own service for those features, instead of modifying the Crypto service? Or is there anything makes this not a viable option? If you are thinking about adding hardware acceleration for some Crypto features, that's indeed covered in Shebu's link. Greetings, Fabian Schmidt From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shebu Varghese Kuriakose via TF-M Sent: Dienstag, 12. Oktober 2021 11:46 To: David Hu <David.Hu(a)arm.com>; Roman.Mazurak(a)infineon.com; tf-m(a)lists.trustedfirmware.org; mbed-tls(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [EXT] Re: [TF-M] Adding platform specific functions to Crypto Service. Caution: EXT Email Hi Roman, I also might not have understood the question completely. As you mention crypto HAL API, here is the specification which defines a standardized mechanism for PSA Crypto implementations to interface with Secure elements and crypto accelerators - https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-driver -interface.md <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co m%2FARMmbed%2Fmbedtls%2Fblob%2Fdevelopment%2Fdocs%2Fproposed%2Fpsa-driver-in terface.md&data=04%7C01%7Cfabian.schmidt%40nxp.com%7C17489158b6384ef5caa308d 98d654ead%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637696288543072051%7C Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC JXVCI6Mn0%3D%7C1000&sdata=uKX4sUH37jNx1%2BvACuN8tBQl05OaXPPnMT9FqMwbhdU%3D&r eserved=0> Also adding mbed-tls mailing list as the thread is crypto related.. Regards, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org <mailto:tf-m-bounces@lists.trustedfirmware.org> > On Behalf Of David Hu via TF-M Sent: Tuesday, October 12, 2021 4:18 AM To: Roman.Mazurak(a)infineon.com <mailto:Roman.Mazurak@infineon.com> ; tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com <mailto:nd@arm.com> > Subject: Re: [TF-M] Adding platform specific functions to Crypto Service. Hi Roman, Are you asking about adding platform specific HAL API to implement PSA Crypto API function? Please correct me if I misunderstand your question. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org <mailto:tf-m-bounces@lists.trustedfirmware.org> > On Behalf Of Roman Mazurak via TF-M Sent: Monday, October 11, 2021 9:45 PM To: tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Adding platform specific functions to Crypto Service. Hi all, We would like to add a number of platform specific functions to Crypto Service API. Is it ok if such functions will not be related to cryptographic service, but such approach allows us to optimize platform design? Is there any initiative to create a Crypto Service HAL API to extend Crypto with custom functions? Best regards, Roman.

4 years, 9 months

3
3
0 0

Re: [mbed-tls] Adding platform specific functions to Crypto Service.

by Shebu Varghese Kuriakose

Hi Roman, I also might not have understood the question completely. As you mention crypto HAL API, here is the specification which defines a standardized mechanism for PSA Crypto implementations to interface with Secure elements and crypto accelerators - https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive… Also adding mbed-tls mailing list as the thread is crypto related.. Regards, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, October 12, 2021 4:18 AM To: Roman.Mazurak(a)infineon.com; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Adding platform specific functions to Crypto Service. Hi Roman, Are you asking about adding platform specific HAL API to implement PSA Crypto API function? Please correct me if I misunderstand your question. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Roman Mazurak via TF-M Sent: Monday, October 11, 2021 9:45 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Adding platform specific functions to Crypto Service. Hi all, We would like to add a number of platform specific functions to Crypto Service API. Is it ok if such functions will not be related to cryptographic service, but such approach allows us to optimize platform design? Is there any initiative to create a Crypto Service HAL API to extend Crypto with custom functions? Best regards, Roman.

4 years, 9 months

1
0
0 0

MbedTLS and IPv4 packet length problem

by Duygu D.

Hello, I am using this example for the source of the my main purpose : https://github.com/straight-coding/LPC407x-NoOS-LWIP-MBEDTLS-HTTPD-KEIL/blo… This example using https but I'm trying to use this example on Modbus Server. This is init function for the server tcp connections: BOOL xMBTCPPortInit( USHORT usTCPPort ) { struct altcp_pcb *pxPCBListenNew, *pxPCBListenOld; BOOL bOkay = (BOOL)FALSE; USHORT usPort; extern struct altcp_tls_config* getTlsConfig(void); tls_config = getTlsConfig(); mbedtls_ssl_conf_dbg(tls_config, my_debug, NULL); mbedtls_debug_set_threshold(5); if( usTCPPort == 0 ) { usPort = MB_TCP_DEFAULT_PORT; } else { usPort = ( USHORT ) usTCPPort; } if( ( pxPCBListenNew = pxPCBListenOld = altcp_tls_new( tls_config,IPADDR_TYPE_ANY) ) == NULL ) { /* Can't create TCP socket. */ bOkay = (BOOL)FALSE; } else if( altcp_bind( pxPCBListenNew, IP_ANY_TYPE, ( u16_t ) usPort ) != ERR_OK ) { /* Bind failed - Maybe illegal port value or in use. */ ( void )altcp_close( pxPCBListenOld ); bOkay = (BOOL)FALSE; } else if( ( pxPCBListenNew = altcp_listen( pxPCBListenNew ) ) == NULL ) { ( void )altcp_close( pxPCBListenOld ); bOkay = (BOOL)FALSE; } else { // altcp_tls_new(pxPCBListenNew, IP_GET_TYPE(ip_addr))*/; /* Register callback function for new clients. */ altcp_accept( pxPCBListenNew, prvxMBTCPPortAccept ); /* Everything okay. Set global variable. */ pxPCBListen = pxPCBListenNew; #ifdef MB_TCP_DEBUG vMBPortLog( MB_LOG_DEBUG, "MBTCP-ACCEPT", "Protocol stack ready.\r\n" ); #endif SerialPrint("MBTCTP-ACCEPT"); } bOkay = (BOOL)TRUE; return bOkay; } struct altcp_tls_config* getTlsConfig(void) { struct altcp_tls_config* conf; size_t privkey_len = strlen(privkey) + 1; size_t privkey_pass_len = strlen(privkey_pass) + 1; size_t cert_len = strlen(cert) + 1; conf = altcp_tls_create_config_server_privkey_cert((u8_t*)privkey, privkey_len, (u8_t*)privkey_pass, privkey_pass_len, (u8_t*)cert, cert_len); return conf; } And I am using basic python tls client example to show successful mbedtls handshake. This is my client.py codes: import time from socket import create_connection from ssl import SSLContext, PROTOCOL_TLS_CLIENT import ssl hostname='example.org' ip = '192.168.1.2' port = 502 context = SSLContext(PROTOCOL_TLS_CLIENT) context.options |= ssl.OP_NO_SSLv3 context.options |= ssl.OP_NO_TLSv1 context.options |= ssl.OP_NO_TLSv1_1 context.load_verify_locations('cert.pem') with create_connection((ip, port)) as client: with context.wrap_socket(client, server_hostname=hostname) as tls: print(f'Using {tls.version()}\n') tls.sendall(b'Hello world') data = tls.recv(1024) print(f'Server says: {data}') When I try to start communication I get below outputs on wireshark: [image: image.png] When the server send hello message I've this error on the line: [image: image.png] When I checked the low_level_output functions I get sending data bytes 150 byte but Ipv4 length shows us 576 byte, opt.h file set as default but if I changed TCP_MSS as a 250 byte so I can send 136 byte and Ipv4 packet lenght shows me 136. But does not make sense. I couldnt do successful handshaking. My mbedtls debug outputs in this link https://paste.ofcode.org/PP3zFmrLcKqPdRMT3LzETz How cna I solve this problem ? What is the reason for the lenght problem ? Best Regards. -- Embeded System Engineer

4 years, 9 months

3
4
0 0

image-20211001180442075

by Shudong Zhang

Hello, I am very sorry about last email by mistakes. I have some questions about multiplication on ecp curves. I add an ecp curve parameter in ecp_curve.c form SM2 algorithm standard, and the parameter is as follow: Then I followed the loading method of secp256r1 to load, but I don’t know how to perform fast calculations, so I commented NIST_MODP( p256 ). #if defined(MBEDTLS_ECP_DP_SECP256R1_ENABLED) caseMBEDTLS_ECP_DP_SECP256R1: NIST_MODP( p256 ); return( LOAD_GROUP( secp256r1 ) ); #endif #if defined(MBEDTLS_ECP_DP_SM256_ENABLED) caseMBEDTLS_ECP_DP_SM256: //NIST_MODP( p256 ); return( LOAD_GROUP_A( sm256 ) ); #endif Then I call the functional interface mbedtls_ecp_mul to perform the multiplication operation, but the heap memory keeps increasing . voidtest() { intret; mbedtls_mpiUd; mbedtls_ecp_groupgrp; mbedtls_ecp_pointT_Q; mbedtls_mpi_init(&Ud); mbedtls_ecp_group_init( &grp ); mbedtls_ecp_point_init( &T_Q ); ret=mbedtls_mpi_read_binary(&Ud, arrUd, sizeof(arr_U_d)); // ret = mbedtls_ecp_group_load(&grp,MBEDTLS_ECP_DP_SECP256R1); ret=mbedtls_ecp_group_load(&grp,MBEDTLS_ECP_DP_SM256); ret=mbedtls_ecp_mul(&grp, &T_Q, &Ud, &(grp.G), NULL, NULL) ; printf("%x\n", -ret); mbedtls_mpi_free(&Ud); mbedtls_ecp_group_free( &grp ); mbedtls_ecp_point_free( &T_Q ); } intmain() { for(inti=0; i<10; i++) test(); return0; } The heap memory is mesaured by massif( valgring tools), Can someone tell me what this is because of and how to fix this problem ? Best Regards. Shudong Zhang

4 years, 10 months

1
0
0 0

Add an ecp curves, but the multiplication add heap memory continuouly

by Shudong Zhang

Hello， I add an ecc curve parameter in ecp_curve.c form SM2 algorithm, and the parameter is as follow:

4 years, 10 months

2
1
0 0

Unable to enable CCM ciphers in mbedtls

by Ron Eggler

The |mbedtls| client project I'm working on, is to also support the cipher suites: |TLS-ECDHE-ECDSA-WITH-AES-256-CCM| & |TLS-ECDHE-ECDSA-WITH-AES-128-CCM|. I have specified them like: |const int ciphersuites[] = { MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA384, MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_CCM, MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_256_CCM, 0 }; mbedtls_ssl_conf_ciphersuites(&ctxt->conf,ciphersuites); | and while I can see the GCM ciphers in the |Client Hello|, I cannot see the |CCM| ciphers. In |mbedtls/include/mbedtls/config.h|, the following are enabled: |#define MBEDTLS_CCM_ALT #define MBEDTLS_CCM_C #define MBEDTLS_ECDH_GEN_PUBLIC_ALT #define MBEDTLS_ECDH_COMPUTE_SHARED_ALT #define MBEDTLS_ECDSA_SIGN_ALT | What is still missing? While CCM is not listed under The following ciphers may be included <https://tls.mbed.org/module-level-design-cipher>, the ciphers i would like to add definitely show up under Supported SSL / TLS ciphersuites <https://tls.mbed.org/supported-ssl-ciphersuites>, Can someone help out?

4 years, 10 months

2
2
0 0

RAM usage and Slowness issue

by Sunil Jain

Hello, *RAM USAGE:* We are using mbedTLS 2.16 for TLS communication and found that it is consuming more RAM compared to other Cybersecurity library (Mocana ) which we were using earlier. I want to reduce the RAM usage, if there are any settings which i can apply to reduce the RAM usage Presently MbedTLS is using almost 38KB of RAM per TLS connection, I have small memory in my device (STM32F437), I want to reduce this RAM consumption to 30KB per TLS connection. *SLOWNESS:* we have found that after 4 TLS connections on STM32F437 controller, communication becomes very slow, we measured the CPU utilization at this point of time, and it's only 40% ustilized, we are not getting any clue why it becomes so slow. When we compare with Mocana cyber security library we were able to run 6 TLS connections with good speed. Please help us with the above 2 topics. -- Thanks and Regards, Sunil Jain

4 years, 10 months

2
1
0 0

TLS 1.3 support

by Alex Sukhov

Hi mbedTLS team, Our teams are in the process of reviewing available TLS library options. Is there any information that we can find with respect to the mbedTLS stance on TLS 1.3 support? I.E is there a timeline available supporting TLS 1.3? Alternatively is there documentation available that outlines the expected deltas between TLS 1.2 and 1.3 that can help compare the value gained by using TLS 1.3 instead of 1.2? Regards, Alex Sukhov Geotab Embedded System Developer, Team Lead Toll-free Visit +1 (877) 431-8221 www.geotab.com Twitter <https://twitter.com/geotab> | Facebook <https://www.facebook.com/Geotab> | YouTube <https://www.youtube.com/user/MyGeotab> | LinkedIn <https://www.linkedin.com/company/geotab/>

4 years, 10 months

3
2
0 0

Doubt in mbedtls version support for libiec61850-1.5

by lekshmi g

When we are using the version *mbedtls-2.16.6* with *libiec61850-1.5*, the TLS connection is established successfully. But when we use the *2.7.19*, the connection fails(we renamed *mbedtls 2.7.19* as *mbedtls 2.16* and put in the folder third_party\mbedtls ). We had occurred following error during the execution of client- server example programs tls_server_example and tls_client_example using 2.7.19 version. During handshaking process till CASE " MBEDTLS_SSL_CLIENT_CHANGE_CIPHER_SPEC " it worked as expected. But In CASE "MBEDTLS_SSL_CLIENT_FINISHED" the return value should be zero. But we got in function mbedtls_ssl_safer_memcmp mac_peer==41155316 mac_expect==41155356 diff=255 (this value has to be 0 for connection establishment) But we are getting 255 constantly in all runnings. Kindly help us to resolve the issue. If this issue is due to the non supporting of mbedtls version ?.Thanks in advance. Please let us know the *supporting versions of mbedtls *for *libiec61850-1.5 *.

4 years, 10 months

2
2
0 0

On the future of on-target testing

by Gilles Peskine

Hello, Mbed TLS supports building and running unit tests in one of two modes: “hosted” or “on target”. The on-target mode relies on Greentea, the Mbed OS test framework. The on-target mode is unmaintained (there's no CI for it and the Mbed TLS maintainers hardly ever even try to build it these days) and we're considering retiring it in Mbed TLS 2.28. If you do use Mbed TLS's on-target unit testing, either by building target_test.function or by plugging your own file instead of target_test.function or host_test.function, please let us know and weigh in on https://github.com/ARMmbed/mbedtls/issues/4912 <https://github.com/ARMmbed/mbedtls/issues/4912> . Best regards, -- Gilles Peskine Mbed TLS developer

4 years, 10 months

1
1
0 0

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

by Shariful Alam

Hello, I'm using an older version of mbedtls (polarssl-1.3.9). I have a plain text private key generated from OpenSSL like the following. I'm trying to load this private key into the *rsa_context *using the following code (sorry, for the following code, I just don't know what to copy), Private key with padding (I have added padding manualy to make it divisible by 16 ) ================================================== // Total private key size is 4013 # define KEY_BUFFER_SIZE 4017 unsigned char private_decrypt[KEY_BUFFER_SIZE]; *printf("private key with padding --> \n %s \n", private_decrypt); --> shows the following* private key with padding --> RSA Private-Key: (2048 bit, 2 primes) modulus: 00:cc:40:c3:c6:e7:29:ae:f5:94:d8:3b:3f:a4:33: c2:6d:29:86:63:db:b7:8c:d4:07:f7:b3:db:96:83: f7:55:dd:6a:7b:04:49:53:3d:52:30:5f:af:0b:c2: b1:f0:48:a4:66:0a:b7:aa:29:b1:d0:91:4f:9c:1c: cf:df:5c:10:04:85:f9:bd:7b:93:ed:a6:77:80:12: 34:64:19:1a:18:b5:4e:94:7c:39:ce:99:38:50:e9: 82:71:f6:0f:3e:b8:af:11:3c:f4:05:69:72:8e:96: f6:81:ac:46:29:eb:88:88:c5:54:2f:89:1b:b9:32: da:76:23:a2:00:76:a5:8e:50:d3:ba:39:35:f9:4d: 95:63:ff:6a:3c:c8:a8:53:aa:78:d8:81:c8:bd:af: cf:6c:de:33:aa:c9:d4:80:2c:1f:ef:92:90:8a:c4: 88:e6:9a:e5:ad:2d:08:60:89:1a:77:fc:bf:68:64: 6f:c0:a7:fa:33:6d:ff:d2:e6:a4:7f:ad:87:be:0c: cb:9d:18:44:57:fe:db:86:7f:0b:c5:f7:9a:29:4b: 61:62:48:91:01:f7:e7:5e:64:4d:20:ec:ac:3c:07: 59:d6:19:f5:8c:01:9f:d5:6e:16:a8:8e:f9:2d:f6: f8:73:25:0a:b5:d8:62:2a:f8:ba:d5:dc:ff:6e:77: 0d:35 publicExponent: 65537 (0x10001) privateExponent: 4a:17:50:2d:2d:9b:5c:40:ef:3e:44:b7:c0:3b:9a: 52:78:d6:ac:10:7e:93:92:32:55:b3:23:7b:84:e1: 4a:7f:67:e9:b9:d3:53:63:92:15:c4:0f:be:47:60: be:95:cb:34:cc:bc:74:f8:6c:ed:08:59:05:7b:1a: 18:9e:cf:9c:a4:70:c4:40:38:97:e3:63:c3:cc:56: be:dc:b0:2f:b8:4d:09:e5:ca:1e:5c:4c:26:65:9e: 10:f2:bd:f2:f5:91:63:c2:65:8e:35:02:fe:20:5a: c9:0d:11:e2:90:f2:d5:12:27:88:9a:c6:b8:b6:6e: b2:9e:18:5c:ec:ac:ff:63:42:94:b3:b5:ff:69:75: f5:e9:41:77:8b:ee:1d:fa:47:78:9a:9c:1f:84:8b: 85:f9:29:a5:27:e4:1f:04:34:4e:ce:c2:28:18:38: 72:63:5c:44:88:4f:e2:ec:bc:c4:3e:af:d8:bb:a9: 0f:c9:30:0f:bf:bc:1d:8a:fc:d9:cf:27:f5:16:38: 34:07:3d:bf:a5:45:70:df:c5:8f:ee:79:3e:69:6e: e4:0c:74:76:f7:8a:2c:11:34:53:60:27:c3:73:55: 62:d5:06:cb:35:a4:3d:d6:79:3f:50:d4:81:7c:0f: 03:c5:15:b2:4a:eb:84:f1:16:07:ec:16:02:e4:5c: 1d prime1: 00:e5:40:6a:4c:8d:d3:8d:8d:e6:df:e7:1d:c4:8f: 4d:b4:b7:71:51:b7:c4:8a:19:fe:fd:3e:4b:a9:0b: d0:22:64:e0:76:f4:8b:88:d6:30:4b:f6:41:ae:20: c5:cc:79:ec:05:d0:6b:0e:64:16:c5:b5:e3:74:b6: a8:ac:39:74:1d:8a:09:b8:68:64:a4:c1:74:fa:f6: cd:1b:24:d6:86:1e:40:51:dc:09:78:76:8b:16:3e: f1:ea:a9:9b:25:69:4a:c4:3e:ba:63:62:6c:06:40: 83:8d:af:69:89:bd:ad:07:f4:97:39:7c:25:59:80: 07:59:4e:74:a0:4b:2a:05:67 prime2: 00:e4:15:a8:6a:e6:30:95:d6:36:44:a7:57:ac:99: d5:4d:d9:58:59:05:49:89:b8:42:cb:0e:e8:9d:12: fc:a4:76:e7:07:11:08:97:05:7d:0a:34:21:23:03: c9:4b:97:5c:6f:fc:7e:28:8a:c5:b1:44:12:61:03: 60:5e:f9:d2:51:cf:53:0f:7a:2f:a5:96:5a:f5:33: f7:6f:6e:92:14:cc:54:b1:48:ad:da:f7:37:c7:ca: 6f:a2:6a:00:de:73:6c:67:59:78:af:e9:ce:fb:02: 95:f8:0d:82:38:02:79:e5:a4:3b:61:16:b7:70:b1: 70:c8:9a:e8:81:c7:cb:fb:03 exponent1: 57:04:78:54:ce:90:ba:6e:5e:70:26:9d:d9:fa:3b: 18:99:78:dd:f7:cf:16:4c:7f:c9:48:58:17:b6:70: 2e:5d:f4:05:b3:15:33:bf:79:5d:9b:ff:9a:44:be: 4f:bb:07:a7:bd:50:a5:89:c0:4b:13:9b:5e:b5:e6: 98:58:c6:86:5f:db:08:b0:37:63:82:3b:10:f7:95: 2a:f4:74:a9:3b:da:56:38:1b:30:2a:6e:e8:e6:c3: 94:bb:04:34:d3:1e:9a:16:e5:50:cc:0f:0c:e0:78: 0e:d3:c2:4f:92:3b:97:85:73:d1:52:1a:2b:3a:b9: 8f:60:84:4c:43:bb:93:89 exponent2: 00:d7:ea:08:bc:e9:9c:24:bb:dc:33:b1:96:b5:b6: 0a:ce:df:69:5b:1c:3e:39:39:4d:41:9c:a3:67:ce: 89:8b:c7:63:7c:b5:0b:44:ab:d5:6a:cb:5e:73:1f: 2a:77:7c:99:ed:09:41:04:70:1a:25:6d:23:58:e3: 31:5f:b7:6e:fa:33:21:96:0d:3c:fd:ac:0f:fe:ff: 6a:c4:fa:0f:1f:d1:2e:7b:85:29:cf:97:28:1e:e1: ec:3b:fb:cd:46:c8:4d:5e:a8:bc:2f:0b:4e:fd:1f: bd:88:4c:81:71:34:26:e0:d5:4f:c0:e1:18:56:7e: 23:1e:44:46:c6:54:b5:2c:b1 coefficient: 2e:45:e5:0a:bc:66:bc:6e:9d:0d:ce:02:d6:30:62: 44:f6:38:d0:a7:2a:25:c4:42:76:cc:59:38:af:35: cb:6e:a7:5e:3c:71:97:6a:7b:c4:69:25:2e:c4:07: 20:2c:86:5c:a1:e8:6e:d8:e6:b7:9a:21:28:1e:8a: b1:4b:c5:ab:4e:35:e0:83:b5:30:56:53:d7:50:2f: 69:a2:6c:7b:00:d8:15:17:bb:79:72:33:30:11:47: 06:c5:58:16:63:e3:f5:ac:71:3d:ce:64:67:0e:6a: e0:cd:c2:e6:ad:30:f9:3e:7e:52:01:cf:fc:fc:66: 10:44:1a:4b:1b:08:7a:8d 000 <----- padding ============================================ Remove padding and get the actual private key using the the following code, ============================================================================= size_t lenght=strlen(private_decrypt); // length =4016 int N= lenght-4013; // 4013 is the original length of the private key, N is the length of padding private_decrypt[lenght-N]='\0'; // So, now *private_decrypt *contains the actual key ============================================================================= Then I use the following code to split each key and load into rsa_context, ===================================================================== char *strings[]={ "modulus:", "publicExponent:", "privateExponent:", "prime1:", "prime2:", "exponent1:", "exponent2:", "coefficient:"}; char* in = &private_decrypt; char *token; const char s[2] = " "; char *token_2; int k=0, size; do { if(k<8){ token = strstr(in,strings[k]); size= strlen(token); if (token){ *token = '\0'; } switch (k) { case 1: strcat(in,"\0"); printf("k=%d:\n %s\n",k,in); mpi_read_string(&rsaContext->N, 16, in); break; case 2: token_2 = strtok_r(in, s, &in); strcat(token_2,"\0"); printf("k=%d:\n %s\n",k,token_2); mpi_read_string(&rsaContext->E, 16, token_2); break; case 3: break; case 4: break; case 5: break; case 6: break; case 7: break; } //printf("k=%d \n%s\n",k,in); in = token+strlen(strings[k]); k=k+1; } else{ token= "NULL"; break; } }while(token!=NULL); // Check Public key if(rsa_check_pubkey(rsaContext)!=0){ printf("Reading public key error\n"); exit(0); } ===================================================================== Upon doing all this, when check the if the public key is load correctly or not, I'm getting *"Reading public key error". *Any help, what I'm doing wrong? Regards, Shariful Alam

4 years, 10 months

1
0
0 0

How can I get plaintext rsa private key from .pem format?

by Shariful Alam

Hello, I found that, /programs/pkeyrsa_genkey.c creates a plaintext rsa private key. Is there any way I can generate the keys in the same format from a .pem format? Regards, Shariful Alam

4 years, 11 months

1
0
0 0

-0x7880 "error" after successful failed download

by Ron Eggler

Hi, I'm getting the following errors printed: tls : error : [2021/06/21 21:43:12.360] [id = 10]: ../../src/../externals/mbedtls/mbedtls/library/ssl_tls.c(4369): mbedtls_ssl_handle_message_type() returned -30848 (-0x7880) tls : error : [2021/06/21 21:43:12.360] [id = 11]: ../../src/../externals/mbedtls/mbedtls/library/ssl_tls.c(8335): mbedtls_ssl_read_record() returned -30848 (-0x7880) after a file is successfully downloaded. It looks like MBEDTLS_ERR_SSL_PEER_CLOSE_NOTIFY gets interpreted and printed as error. How can I fix this? Is this a configuration thing or do I edit the ssl_tls.c source code? Thank you, Ron mbedtls 2.16.0

4 years, 11 months

1
0
0 0

Re: [mbed-tls] FTPS: Bad Record Mac on login

by Ron Eggler

On 2021-08-16 11:11 a.m., Ron Eggler via mbed-tls wrote: > Hi, > > I am working on a client where I need to login to a FTPS server > (vsftpd). I establish the connection, exchange Hellos, certificate & > key exchange and all seems succesful and are happening fine. > > I am able to send "PBSZ 0" to the server which gets acknowledged with > "200 PBSZ set to 0." (as seen in Wireshark). > > Then, when it comes to sending "PROT P", I cannot see it encoded in > Wireshark. it just says "Application Data" and the next frame reads > "Alert (Level: Fatal, Description: Bad Record Mac)". I have > investigated my code (mostly for differences between "PBSZ 0" and > "PROT P" but came up empty) and have searched the web but have failed > to find the resolution to my problem, as of yet. It seems obvious that > the problem must be in my code but I seem to be unable to put my > finger on it! I thought I should check if someone here may have any > other hints that will help me resolve the problem. > > I have temporarily set "mbedtls_ssl_conf_authmode( &ctxt.conf, > MBEDTLS_SSL_VERIFY_NONE);" to make sure that the CA is not the causing > any issues. > I have been able to resolve this. It was caused by usage of different context structure pointers.

4 years, 11 months

1
0
0 0

FTPS: Bad Record Mac on login

by Ron Eggler

Hi, I am working on a client where I need to login to a FTPS server (vsftpd). I establish the connection, exchange Hellos, certificate & key exchange and all seems succesful and are happening fine. I am able to send "PBSZ 0" to the server which gets acknowledged with "200 PBSZ set to 0." (as seen in Wireshark). Then, when it comes to sending "PROT P", I cannot see it encoded in Wireshark. it just says "Application Data" and the next frame reads "Alert (Level: Fatal, Description: Bad Record Mac)". I have investigated my code (mostly for differences between "PBSZ 0" and "PROT P" but came up empty) and have searched the web but have failed to find the resolution to my problem, as of yet. It seems obvious that the problem must be in my code but I seem to be unable to put my finger on it! I thought I should check if someone here may have any other hints that will help me resolve the problem. I have temporarily set "mbedtls_ssl_conf_authmode( &ctxt.conf, MBEDTLS_SSL_VERIFY_NONE);" to make sure that the CA is not the causing any issues. Thank you!

4 years, 11 months

1
0
0 0

record and no record delemma

by Dave Plater

Hi, I wonder if anyone can tell me what I'm doing wrong. I use a modified client1.c for getting payment objects from an aws address, curl says that the connection uses "SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256" if it's any use. I can retrieve any single payment object which has a content length of about 443 but when I try to get the entire record of payments of which I only need the first or latest payment to check that I'm in sync, I get "Last error was: -28928 - SSL - Bad input parameters to function". This started at a certain point in the payment object accumulation don't quite know when, the current record of all payments is 22526 and it grows with every transaction. The GET request for the all the payment objects ends in "/payments/" and for a single object /payments/ has the objects id appended to it. There must be a way to receive a truncated record of all payments. Here is my latest config.h: #ifndef MBEDTLS_CONFIG_H #define MBEDTLS_CONFIG_H /* System support */ //#define MBEDTLS_HAVE_ASM #define MBEDTLS_HAVE_TIME #define MBEDTLS_NO_PLATFORM_ENTROPY #define MBEDTLS_NO_DEFAULT_ENTROPY_SOURCES #define MBEDTLS_TEST_NULL_ENTROPY #define MBEDTLS_ERROR_C #define MBEDTLS_PLATFORM_C //#define MBEDTLS_PLATFORM_EXIT_ALT //#define MBEDTLS_PLATFORM_TIME_ALT //#define MBEDTLS_PLATFORM_FPRINTF_ALT //#define MBEDTLS_PLATFORM_PRINTF_ALT //#define MBEDTLS_PLATFORM_SNPRINTF_ALT //#define MBEDTLS_PLATFORM_VSNPRINTF_ALT //#define MBEDTLS_PLATFORM_NV_SEED_ALT //#define MBEDTLS_PLATFORM_SETUP_TEARDOWN_ALT /* mbed TLS feature support */ #define MBEDTLS_CIPHER_MODE_CBC #define MBEDTLS_PKCS1_V15 #define MBEDTLS_KEY_EXCHANGE_RSA_ENABLED #define MBEDTLS_SSL_PROTO_TLS1_2 #define MBEDTLS_SSL_CLI_C #define MBEDTLS_SSL_TLS_C #define MBEDTLS_ENTROPY_C #define MBEDTLS_NO_DEFAULT_ENTROPY_SOURCES //experiment #define MBEDTLS_KEY_EXCHANGE_RSA_ENABLED #define MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED #define MBEDTLS_ECDH_C #define MBEDTLS_ECP_C #define MBEDTLS_ECP_DP_SECP192R1_ENABLED #define MBEDTLS_RSA_C #define MBEDTLS_OID_C #define MBEDTLS_PKCS1_V15 #define MBEDTLS_X509_CRT_PARSE_C #define MBEDTLS_CIPHER_C #define MBEDTLS_MD_C #define MBEDTLS_BIGNUM_C #define MBEDTLS_SHA256_C #define MBEDTLS_PK_PARSE_C #define MBEDTLS_PK_C #define MBEDTLS_ASN1_PARSE_C /* mbed TLS modules */ #define MBEDTLS_AES_C /* #define MBEDTLS_ASN1_WRITE_C #define MBEDTLS_BIGNUM_C #define MBEDTLS_CIPHER_C #define MBEDTLS_CTR_DRBG_C #define MBEDTLS_DES_C #define MBEDTLS_MD_C #define MBEDTLS_MD5_C //#define MBEDTLS_RSA_C #define MBEDTLS_SHA1_C #define MBEDTLS_SHA256_C */ #define MBEDTLS_X509_USE_C /* For test certificates */ #define MBEDTLS_BASE64_C #define MBEDTLS_CERTS_C #define MBEDTLS_PEM_PARSE_C /* Limit memory use*/ #define MBEDTLS_SSL_MAX_CONTENT_LEN 16384 /* For testing with compat.sh */ //#define MBEDTLS_FS_IO #include "check_config.h" #endif /* MBEDTLS_CONFIG_H */ Thanks, Dave P

4 years, 11 months

1
0
0 0

Compare certs' RSA keys, subjects etc..

by Nassim Eddequiouaq

Hi, I'd like to compare a signing cert in a cert chain against a pinned cert. Given two mbedtls_x509_crt (or two mbedtls_rsa_context), what is the recommended way to compare them? Thanks! -- Nassim Eddequiouaq

4 years, 11 months

1
0
0 0

Re: [mbed-tls] Could memory leak or heap fragmentation be the issue?

by Gilles Peskine

Hello, I don't see anything obviously wrong with the code. Heap fragmentation is a possibility. A memory leak is also a possibility; we do fairly extensive testing for memory leaks in unit tests, but this doesn't catch unusual conditions (especially not recovering after a low-memory condition). I think the first tool to investigate is to enable MBEDTLS_MEMORY_DEBUG. This has a small cost in code size and gives you access to some introspection functions mbedtls_memory_buffer_alloc_status() and mbedtls_memory_buffer_alloc_max_get(). Call these functions on an error, and also perhaps at other times for comparison. There's also an option MBEDTLS_MEMORY_BACKTRACE which creates extremely verbose logs. Those logs might be helpful, but they're so verbose that they often aren't practical in a real-world application. I notice that the allocation is for a little over 16kB. The default size of the SSL input/output buffers is 16kB because that's the maximum size of a message according to the specification. However you can usually get away with a lot less, especially on IoT networks where the infrastructure is geared towards much smaller messages. See https://tls.mbed.org/kb/how-to/controlling_package_size <https://tls.mbed.org/kb/how-to/controlling_package_size> for more information on message sizes and buffer sizes. If the problem is a memory leak, smaller buffers will only delay the failure. But if the problem is that the application just needs a bit more heap space, this could solve the problem. Concretely, try setting MBEDTLS_SSL_IN_CONTENT_LEN and MBEDTLS_SSL_OUT_CONTENT_LEN in the compile-time configuration to much lower values. MBEDTLS_SSL_OUT_CONTENT_LEN can be as low as you like as long as the handshake messages fit. MBEDTLS_SSL_IN_CONTENT_LEN has to be large enough for the messages that you're sent. Alternatively, enable the option MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH, which results in smaller buffers but can make fragmentation worse due to reallocations. Hope this helps. -- Gilles Peskine Mbed TLS developer On 01/08/2021 22:40, Alan Chen via mbed-tls wrote: > > I posted the question on the mbedTLS forum, only to realized that > mbedTLS is now maintained by the projectï¿½s mailing list. Here is the > copy of what I wrote: > > ï¿½ > > *Occasionally*ï¿½ I am getting MBEDTLS_ERR_SSL_ALLOC_FAILED from > mbedtls_ssl_setup() during repeated HTTP partial content download. > Since this problem happens very rarely, it is a bit difficult to > troubleshoot. > > ï¿½ > > I am running mbedTLS on a Microchip PIC32MZ MCU, connected to a > LTE-M/NB-IoT modem. I have 128K static memory reserved for the library > with MBEDTLS_PLATFORM_MEMORY defined in the config.h file. The MCU > runs two main tasks - MQTT client, talking to the AWS MQTT broker, and > HTTPS client, for downloading new firmware image from the AWS S3 > bucket over the air. > > ï¿½ > > Due to the slowness and limited bandwidth of the LTE-M and NB-IoT > technologies, the HTTP file download has to use the partial content > GET, basically 2KB per request, until all ~700KB of data are received. > During the course of the file download, one can see as many as 30 > disconnect and reconnect, and each time the TLS session would close > down and re-open once the cell network is established. Here are some > of my functions: > > ï¿½ > > ``` > > #define MBEDTLS_MAX_MEMORY_ALLOCATEDï¿½ï¿½ï¿½ (1024 * 128) > > static uint8_t tls_memory_buf[MBEDTLS_MAX_MEMORY_ALLOCATED]; > > ï¿½ > > // called in main() > > void mbedtls_mem_init(void) > > { > > ï¿½ï¿½ï¿½ mbedtls_memory_buffer_alloc_init(tls_memory_buf, sizeof > tls_memory_buf); > > } > > ï¿½ > > void HTTPS_TLS_CLOSE(void) > > { > > ï¿½ï¿½ï¿½ if (server_fd_https.fd != -1) > > ï¿½ï¿½ï¿½ {ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½mbedtls_entropy_free(&entropy_https); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ mbedtls_x509_crt_free(&cacert_https); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ mbedtls_ctr_drbg_free(&ctr_drbg_https); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ mbedtls_ssl_config_free(&conf_https); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ mbedtls_ssl_free(&ssl_https); > > ï¿½ > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ server_fd_https.fd = -1; > > ï¿½ï¿½ï¿½ } > > } > > ï¿½ > > bool HTTPS_TLS_OPEN(void) > > { > > ï¿½ï¿½ï¿½ int ret; > > ï¿½ï¿½ï¿½ const char *pers = "https_tls_wrapper"; > > ï¿½ > > ï¿½ > > ï¿½ï¿½ï¿½ server_fd_https.fd = 1; > > ï¿½ï¿½ï¿½ mbedtls_debug_set_threshold(1); > > ï¿½ > > ï¿½ï¿½ï¿½ mbedtls_ssl_init(&ssl_https); > > ï¿½ï¿½ï¿½ mbedtls_ssl_config_init(&conf_https); > > ï¿½ï¿½ï¿½ mbedtls_ctr_drbg_init(&ctr_drbg_https); > > ï¿½ï¿½ï¿½ mbedtls_x509_crt_init(&cacert_https); > > ï¿½ï¿½ï¿½ > > ï¿½ï¿½ï¿½ï¿½mbedtls_entropy_init(&entropy_https);ï¿½ï¿½ï¿½ > > ï¿½ï¿½ï¿½ï¿½mbedtls_entropy_add_source(&entropy_https, my_https_entropy, NULL, > sizeof my_https_random, MBEDTLS_ENTROPY_SOURCE_STRONG); > > ï¿½ï¿½ï¿½ > > ï¿½ï¿½ï¿½ï¿½ret = mbedtls_ctr_drbg_seed(&ctr_drbg_https, mbedtls_entropy_func, > &entropy_https, (const unsigned char *)pers, strlen(pers)); > > ï¿½ï¿½ï¿½ if (ret != 0) > > ï¿½ï¿½ï¿½ { > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ printf("%s: mbedtls_ctr_drbg_seed ERROR -0x%x\r\n", > __FUNCTION__, -ret); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ return false; > > ï¿½ï¿½ï¿½ } > > ï¿½ > > ï¿½ï¿½ï¿½ ret = mbedtls_x509_crt_parse(&cacert_https, TRUSTED_ROOT_CA, > TRUSTED_ROOT_CA_SIZE); > > ï¿½ï¿½ï¿½ if (ret != 0) > > ï¿½ï¿½ï¿½ { > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ printf("%s: mbedtls_x509_crt_parse cacert ERROR -0x%x\r\n", > __FUNCTION__, -ret); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ return false; > > ï¿½ï¿½ï¿½ } > > ï¿½ï¿½ï¿½ > > ï¿½ï¿½ï¿½ï¿½ret = mbedtls_ssl_config_defaults(&conf_https, > MBEDTLS_SSL_IS_CLIENT, MBEDTLS_SSL_TRANSPORT_STREAM, > MBEDTLS_SSL_PRESET_DEFAULT); > > ï¿½ï¿½ï¿½ if (ret != 0) > > ï¿½ï¿½ï¿½ { > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ printf("%s: mbedtls_ssl_config_defaults ERROR -0x%x\r\n", > __FUNCTION__, -ret); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ return false; > > ï¿½ï¿½ï¿½ } > > ï¿½ > > ï¿½ï¿½ï¿½ mbedtls_ssl_conf_verify(&conf_https, NULL, NULL); > > ï¿½ï¿½ï¿½ mbedtls_ssl_conf_authmode(&conf_https, MBEDTLS_SSL_VERIFY_REQUIRED); > > ï¿½ï¿½ï¿½ mbedtls_ssl_conf_rng(&conf_https, mbedtls_ctr_drbg_random, > &ctr_drbg_https); > > ï¿½ï¿½ï¿½ mbedtls_ssl_conf_dbg(&conf_https, my_https_debug, stdout); > > ï¿½ï¿½ï¿½ mbedtls_ssl_conf_ca_chain(&conf_https, &cacert_https, NULL); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > > ï¿½ï¿½ï¿½ï¿½mbedtls_ssl_conf_read_timeout(&conf_https, TLS_TIMEOUT_MS); > > ï¿½ > > ï¿½ï¿½ï¿½ HTTPS_SetHostname(); /* calling mbedtls_ssl_set_hostname */ > > ï¿½ï¿½ï¿½ > > ï¿½ï¿½ï¿½ï¿½ret = mbedtls_ssl_setup(&ssl_https, &conf_https); > > ï¿½ï¿½ï¿½ if (ret != 0) > > ï¿½ï¿½ï¿½ { > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ printf("%s: mbedtls_ssl_setup ERROR -0x%x\r\n", __FUNCTION__, > -ret); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ return false; > > ï¿½ï¿½ï¿½ } > > ï¿½ > > ï¿½ï¿½ï¿½ mbedtls_ssl_set_bio(&ssl_https, &server_fd_https, > mbedtls_https_send, mbedtls_https_recv, NULL); > > ï¿½ > > ï¿½ï¿½ï¿½ return true; > > } > > ``` > > Can someone please tell me if I am doing something inappropriate here? > I am speculating that perhaps there is a memory leak or the heap > becomes so fragmented that it fails on mbedtls_calloc(). The exact > error message in my case is: > > ï¿½ > > > ../mbedtls_lib/ssl_tls.c:5661: alloc(16717 bytes) failed > > ï¿½ > > Thanks. > > ï¿½ > > Alan Chen > > > > ------------------------------------------------------------------------ > <https://home.mcafee.com/utm_medium=email&utm_source=link&utm_campaign=sig-e…> > Scanned by McAfee > <https://home.mcafee.com/utm_medium=email&utm_source=link&utm_campaign=sig-e…> > and confirmed virus-free. > >

4 years, 11 months

1
0
0 0

R: Re: Mbed TLS: long term support versions

by matteo.cogi＠alice.it

Hi Dave and Gilles, Perfect, so I will wait for the last 2.x (presumably the 2.28.x) strand of the version later this year. Thanks again. Regards, Matteo ------ Messaggio Originale ------ Da: mbed-tls(a)lists.trustedfirmware.org A: Gilles.Peskine(a)arm.com; mbed-tls(a)lists.trustedfirmware.org Inviato: giovedì 29 luglio 2021 15:33 Oggetto: Re: [mbed-tls] Mbed TLS: long term support versions Sorry, just realised that myself! Gilles is correct, I should have said 2.28. Thanks Dave On 29/07/2021, 14:25, "mbed-tls on behalf of Gilles Peskine via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: Off-by-one error! The current 2.x release is 2.27.0. Most development work is happening on 3.x but there will be at least one more 2.x release: 2.28.0. The last 2.x release will become an LTS. -- Gilles Peskine Mbed TLS developer On 29/07/2021 15:05, Dave Rodgman via mbed-tls wrote: > > Hi Matteo, > > > > We expect to release an LTS later this year. It’s likely to be 2.27, > and very likely will be supported for the usual LTS period of 3 years. > > > > So if you are considering updating to a new LTS, you could use 2.26 > for prototyping in the short term until the LTS becomes available. The > upcoming LTS will be API-compatible with 2.26. > > > > Hope this helps, > > > > Dave > > > > *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on > behalf of "matteo.cogi--- via mbed-tls" > <mbed-tls(a)lists.trustedfirmware.org> > *Reply to: *"matteo.cogi(a)alice.it" <matteo.cogi(a)alice.it> > *Date: *Tuesday, 27 July 2021 at 07:44 > *To: *"mbed-tls(a)lists.trustedfirmware.org" > <mbed-tls(a)lists.trustedfirmware.org> > *Subject: *[mbed-tls] Mbed TLS: long term support versions > > > > Dear all, > I wish to know which are the future LTS (Long Term Support) versions > for Mbed TLS. > In these last years I have been working with the 2.16.x, but I read it > will be maintained until at least the end of 2021 ( > https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra… > <https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra…> > ), so I am considering an update to a newer LTS version. > However I don’t find which are the next LTS version and for how much > time they will be maintained. > Thanks in advance. > Regards, > Matteo > > -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

4 years, 12 months

1
0
0 0

Re: [mbed-tls] How to setup config.h to make memory_buffer_alloc_init() thread-safe?

by Gilles Peskine

(Note: I'm replying to the list. Please keep list conversations on the list.) Writing memory allocators is a specialty. It's not my specialty, and apparently it's not your specialty either, so if we design a memory allocator we're likely to end up with poor performance. On most systems, the standard library malloc is designed by experts, and often fine-tuned for the type of platform and usage (e.g. large or small pools, with or without MMU, with or without cache). memory_buffer_alloc uses an array to implement malloc. One possible explanation for poor performance is if your allocator doesn't align data nicely. Some platforms supports unaligned accesses (e.g. accessing a 4-byte value at an address that isn't a multiple of 4) but with a significant performance penalty (most others just crash). If there's a cache, alignment with cache line boundaries can also help. Another potential reason in a multithreaded program is not doing synchronization efficiently, or doing it too often. Note that you do NOT need synchronization if each thread has its own memory pool and no thread ever modifies the data of another thread. Note, however, that Mbed TLS caches some data in public/private key objects, so doing an operation with a key modifies the key object, therefore each thread would need to have its own copy of the key. There are undoubtedly other likely reasons that I'm not thinking of. Best regards, -- Gilles Peskine Mbed TLS developer On 29/07/2021 22:38, Shariful Alam wrote: > Hi Gilles, > Hope you are well. The project that I'm currently working on requires > static memory allocation instead of dynamic memory allocation. I was > trying to use "memory_buffer_alloc()". Since memory_buffer_alloc() > doesn't support multiple memory pools, seems like I can't use this > function in my project. > > I have a working version of a modified bignum.c & bignum.h, where > malloc is replaced with an array. The library is working. However, the > performance is poor (~4 times slower). I was wondering what could > cause this slow performance. I mean, I understand it will be slow, but > I did not expect it to be 4 times slower. > > Is there any version, where an array was used instead of malloc? Or if > you could point out some of the reasons for this library to slow down > while using an array, I will be very grateful. > > Best regards, > Shariful > > > On Tue, Jul 20, 2021 at 2:22 PM Gilles Peskine <gilles.peskine(a)arm.com > <mailto:gilles.peskine@arm.com>> wrote: > > Hi Shariful, > > You just call mbedtls_calloc() (or let other functions call it). > It will use the memory pool set by mbedtls_memory_buffer_alloc_init(). > > The memory_buffer_alloc module does not support multiple memory > pools. If you want a separate pool for each thread's allocation > for performance reasons on a multicore system, you'd better rely > on your platform's built-in calloc(). It's likely to be > fined-tuned for multicore operation. The built-in allocator in > Mbed TLS is intended for highly resource-constrained systems where > the basic platform doesn't even include an allocator. > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > On 20/07/2021 22:10, Shariful Alam wrote: >> Hi Gilles, >> Thank you very much, for your reply. Sorry to bother you again. I >> am trying to follow your instructions. I have a question >> regarding your suggestions. >> >> You said "applications call mbedtls_memory_buffer_alloc_init() in >> the startup code of the initial thread, before creating other >> threads. The alloc/free functions are thread-safe, but the >> initialization and deinitialization functions aren't." >> >> I'm a little confused here. Say, if I call >> mbedtls_memory_buffer_alloc_init() with a buffer in the main >> thread, how did all other threads use this memory (or how do all >> the threads know which memory block to use)? >> >> After calling mbedtls_memory_buffer_alloc_init() in the main >> thread, I can get the address of the buffer and pass it to the >> threads, do I have to call mbedtls_memory_buffer_alloc_init() >> again inside each thread? >> >> Thanks, >> Shariful >> >> On Mon, Jul 19, 2021 at 3:48 AM Gilles Peskine via mbed-tls >> <mbed-tls(a)lists.trustedfirmware.org >> <mailto:mbed-tls@lists.trustedfirmware.org>> wrote: >> >> Hi Shariful, >> >> First, please note that the library called PolarSSL with >> functions like >> rsa_private() and memory_buffer_alloc_init() has not been >> supported for >> several years. You should upgrade to Mbed TLS, with functions >> like >> mbedtls_rsa_private() and mbedtls_memory_buffer_alloc_init(). >> That being >> said, the memory_buffer_alloc module works in the same way. >> >> Normally, applications call >> mbedtls_memory_buffer_alloc_init() in the >> startup code of the initial thread, before creating other >> threads. The >> alloc/free functions are thread-safe, but the initialization and >> deinitialization functions aren't. If you must call >> mbedtls_memory_buffer_alloc_init() after creating other >> threads, make >> sure that no thread calls mbedtls_calloc until >> mbedtls_memory_buffer_alloc_init() has returned. >> >> The same principle applies to other parts of Mbed TLS that are >> thread-safe. For example, only the RSA operations (encryption, >> decryption, signature, verification, and also the low-level >> functions >> mbedtls_rsa_public() and mbedtls_rsa_private()) are >> protected. So you >> must finish setting up the RSA key inside one thread before >> you pass a >> pointer to other threads. Similarly, only >> mbedtls_xxx_drbg_random() is >> thread-safe, and the RNG setup (including >> mbedtls_xxx_drgb_seed()) >> should be done as part of the initial application startup. >> >> Finally, note that mbedtls_rsa_private() alone cannot decrypt >> a message: >> all it does it to apply the private key operation. To decrypt >> a simple >> message encrypted with RSA-OAEP, call >> mbedtls_rsa_rsaes_oaep_decrypt() >> or mbedtls_rsa_pkcs1_decrypt() with a key set up for >> MBEDTLS_RSA_PKCS_V21 encoding. To use the legacy PKCS#1v1.5 >> mechanism, >> call mbedtls_rsa_rsaes_pkcs1_v15_decrypt() or >> mbedtls_rsa_pkcs1_decrypt() with a key set up for >> .MBEDTLS_RSA_PKCS_V15. >> To decrypt a message using a RSA FDH hybrid scheme, you do >> need to call >> mbedtls_rsa_private() since Mbed TLS doesn't support it >> natively, but >> what this gives you is the intermediate secret from which you >> then need >> to derive a symmetric key, not the message itself. >> >> Best regards, >> >> -- >> Gilles Peskine >> Mbed TLS developer >> >> On 18/07/2021 07:16, Shariful Alam via mbed-tls wrote: >> > Hello, >> > I have a simple example code to decrypt an >> encrypted message using >> > *rsa_private()*. I use *memory_buffer_alloc_init(), *in >> order to use >> > a static memory for the computation. I want to run my code >> > concurrently. My code works with a single pthread. However, >> when I try >> > to run more than one thread my program fails to decrypt. >> > >> > ** I check the same code >> without *memory_buffer_alloc_init(), *it >> > works concurrently, without any issues at all. >> > >> > Therefore, I believe, the issue that I'm facing is >> coming from the use >> > of static memory(e.g. *memory_buffer_alloc_init()*). The >> documentation >> > of memorry_buffer_alloc.h shows, >> > >> > /** >> > >> > * \brief Initialize use of stack-based memory allocator. >> > >> > * The stack-based allocator does memory >> management >> > inside the >> > >> > * presented buffer and does not call malloc() >> and free(). >> > >> > * It sets the global polarssl_malloc() and >> > polarssl_free() pointers >> > >> > * to its own functions. >> > >> > * (Provided polarssl_malloc() and >> polarssl_free() are >> > thread-safe if >> > >> > * POLARSSL_THREADING_C is defined) >> > >> > * >> > >> > * \note This code is not optimized and provides a >> straight-forward >> > >> > * implementation of a stack-based memory >> allocator. >> > >> > * >> > >> > * \param buf buffer to use as heap >> > >> > * \param len size of the buffer >> > >> > * >> > >> > * \return 0 if successful >> > >> > */ >> > >> > >> > So, I added the following configuration to the *config.h* >> file >> > >> > 1. #define POLARSSL_THREADING_PTHREAD >> > 2. #define POLARSSL_THREADING_C >> > >> > But I'm still getting errors while decrypting. Any help on >> how to fix >> > this? or what else should I add into the config.h file to >> > make *memory_buffer_alloc_init() *thread-safe? Here is my >> sample >> > code: https://pastebin.com/uyW3vknt >> <https://pastebin.com/uyW3vknt> >> <https://pastebin.com/uyW3vknt <https://pastebin.com/uyW3vknt>> >> > >> > Thanks, >> > Shariful >> > >> >> -- >> mbed-tls mailing list >> mbed-tls(a)lists.trustedfirmware.org >> <mailto:mbed-tls@lists.trustedfirmware.org> >> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls >> <https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls> >> >

4 years, 12 months

1
0
0 0

Could memory leak or heap fragmentation be the issue?

by Alan Chen

I posted the question on the mbedTLS forum, only to realized that mbedTLS is now maintained by the project's mailing list. Here is the copy of what I wrote: *Occasionally* I am getting MBEDTLS_ERR_SSL_ALLOC_FAILED from mbedtls_ssl_setup() during repeated HTTP partial content download. Since this problem happens very rarely, it is a bit difficult to troubleshoot. I am running mbedTLS on a Microchip PIC32MZ MCU, connected to a LTE-M/NB-IoT modem. I have 128K static memory reserved for the library with MBEDTLS_PLATFORM_MEMORY defined in the config.h file. The MCU runs two main tasks - MQTT client, talking to the AWS MQTT broker, and HTTPS client, for downloading new firmware image from the AWS S3 bucket over the air. Due to the slowness and limited bandwidth of the LTE-M and NB-IoT technologies, the HTTP file download has to use the partial content GET, basically 2KB per request, until all ~700KB of data are received. During the course of the file download, one can see as many as 30 disconnect and reconnect, and each time the TLS session would close down and re-open once the cell network is established. Here are some of my functions: ``` #define MBEDTLS_MAX_MEMORY_ALLOCATED (1024 * 128) static uint8_t tls_memory_buf[MBEDTLS_MAX_MEMORY_ALLOCATED]; // called in main() void mbedtls_mem_init(void) { mbedtls_memory_buffer_alloc_init(tls_memory_buf, sizeof tls_memory_buf); } void HTTPS_TLS_CLOSE(void) { if (server_fd_https.fd != -1) { mbedtls_entropy_free(&entropy_https); mbedtls_x509_crt_free(&cacert_https); mbedtls_ctr_drbg_free(&ctr_drbg_https); mbedtls_ssl_config_free(&conf_https); mbedtls_ssl_free(&ssl_https); server_fd_https.fd = -1; } } bool HTTPS_TLS_OPEN(void) { int ret; const char *pers = "https_tls_wrapper"; server_fd_https.fd = 1; mbedtls_debug_set_threshold(1); mbedtls_ssl_init(&ssl_https); mbedtls_ssl_config_init(&conf_https); mbedtls_ctr_drbg_init(&ctr_drbg_https); mbedtls_x509_crt_init(&cacert_https); mbedtls_entropy_init(&entropy_https); mbedtls_entropy_add_source(&entropy_https, my_https_entropy, NULL, sizeof my_https_random, MBEDTLS_ENTROPY_SOURCE_STRONG); ret = mbedtls_ctr_drbg_seed(&ctr_drbg_https, mbedtls_entropy_func, &entropy_https, (const unsigned char *)pers, strlen(pers)); if (ret != 0) { printf("%s: mbedtls_ctr_drbg_seed ERROR -0x%x\r\n", __FUNCTION__, -ret); return false; } ret = mbedtls_x509_crt_parse(&cacert_https, TRUSTED_ROOT_CA, TRUSTED_ROOT_CA_SIZE); if (ret != 0) { printf("%s: mbedtls_x509_crt_parse cacert ERROR -0x%x\r\n", __FUNCTION__, -ret); return false; } ret = mbedtls_ssl_config_defaults(&conf_https, MBEDTLS_SSL_IS_CLIENT, MBEDTLS_SSL_TRANSPORT_STREAM, MBEDTLS_SSL_PRESET_DEFAULT); if (ret != 0) { printf("%s: mbedtls_ssl_config_defaults ERROR -0x%x\r\n", __FUNCTION__, -ret); return false; } mbedtls_ssl_conf_verify(&conf_https, NULL, NULL); mbedtls_ssl_conf_authmode(&conf_https, MBEDTLS_SSL_VERIFY_REQUIRED); mbedtls_ssl_conf_rng(&conf_https, mbedtls_ctr_drbg_random, &ctr_drbg_https); mbedtls_ssl_conf_dbg(&conf_https, my_https_debug, stdout); mbedtls_ssl_conf_ca_chain(&conf_https, &cacert_https, NULL); mbedtls_ssl_conf_read_timeout(&conf_https, TLS_TIMEOUT_MS); HTTPS_SetHostname(); /* calling mbedtls_ssl_set_hostname */ ret = mbedtls_ssl_setup(&ssl_https, &conf_https); if (ret != 0) { printf("%s: mbedtls_ssl_setup ERROR -0x%x\r\n", __FUNCTION__, -ret); return false; } mbedtls_ssl_set_bio(&ssl_https, &server_fd_https, mbedtls_https_send, mbedtls_https_recv, NULL); return true; } ``` Can someone please tell me if I am doing something inappropriate here? I am speculating that perhaps there is a memory leak or the heap becomes so fragmented that it fails on mbedtls_calloc(). The exact error message in my case is: > ../mbedtls_lib/ssl_tls.c:5661: alloc(16717 bytes) failed Thanks. Alan Chen ________________________________ [https://secureimages.mcafee.com/common/affiliateImages/mfe/logo.png]<https://home.mcafee.com/utm_medium=email&utm_source=link&utm_campaign=sig-e…> Scanned by McAfee<https://home.mcafee.com/utm_medium=email&utm_source=link&utm_campaign=sig-e…> and confirmed virus-free.

4 years, 12 months

1
0
0 0

Re: [mbed-tls] Mbed TLS: long term support versions

by Dave Rodgman

Sorry, just realised that myself! Gilles is correct, I should have said 2.28. Thanks Dave On 29/07/2021, 14:25, "mbed-tls on behalf of Gilles Peskine via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: Off-by-one error! The current 2.x release is 2.27.0. Most development work is happening on 3.x but there will be at least one more 2.x release: 2.28.0. The last 2.x release will become an LTS. -- Gilles Peskine Mbed TLS developer On 29/07/2021 15:05, Dave Rodgman via mbed-tls wrote: > > Hi Matteo, > > > > We expect to release an LTS later this year. It’s likely to be 2.27, > and very likely will be supported for the usual LTS period of 3 years. > > > > So if you are considering updating to a new LTS, you could use 2.26 > for prototyping in the short term until the LTS becomes available. The > upcoming LTS will be API-compatible with 2.26. > > > > Hope this helps, > > > > Dave > > > > *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on > behalf of "matteo.cogi--- via mbed-tls" > <mbed-tls(a)lists.trustedfirmware.org> > *Reply to: *"matteo.cogi(a)alice.it" <matteo.cogi(a)alice.it> > *Date: *Tuesday, 27 July 2021 at 07:44 > *To: *"mbed-tls(a)lists.trustedfirmware.org" > <mbed-tls(a)lists.trustedfirmware.org> > *Subject: *[mbed-tls] Mbed TLS: long term support versions > > > > Dear all, > I wish to know which are the future LTS (Long Term Support) versions > for Mbed TLS. > In these last years I have been working with the 2.16.x, but I read it > will be maintained until at least the end of 2021 ( > https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra… > <https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra…> > ), so I am considering an update to a newer LTS version. > However I don’t find which are the next LTS version and for how much > time they will be maintained. > Thanks in advance. > Regards, > Matteo > > -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

4 years, 12 months

1
0
0 0

Re: [mbed-tls] Mbed TLS: long term support versions

by Gilles Peskine

Off-by-one error! The current 2.x release is 2.27.0. Most development work is happening on 3.x but there will be at least one more 2.x release: 2.28.0. The last 2.x release will become an LTS. -- Gilles Peskine Mbed TLS developer On 29/07/2021 15:05, Dave Rodgman via mbed-tls wrote: > > Hi Matteo, > > > > We expect to release an LTS later this year. It’s likely to be 2.27, > and very likely will be supported for the usual LTS period of 3 years. > > > > So if you are considering updating to a new LTS, you could use 2.26 > for prototyping in the short term until the LTS becomes available. The > upcoming LTS will be API-compatible with 2.26. > > > > Hope this helps, > > > > Dave > > > > *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on > behalf of "matteo.cogi--- via mbed-tls" > <mbed-tls(a)lists.trustedfirmware.org> > *Reply to: *"matteo.cogi(a)alice.it" <matteo.cogi(a)alice.it> > *Date: *Tuesday, 27 July 2021 at 07:44 > *To: *"mbed-tls(a)lists.trustedfirmware.org" > <mbed-tls(a)lists.trustedfirmware.org> > *Subject: *[mbed-tls] Mbed TLS: long term support versions > > > > Dear all, > I wish to know which are the future LTS (Long Term Support) versions > for Mbed TLS. > In these last years I have been working with the 2.16.x, but I read it > will be maintained until at least the end of 2021 ( > https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra… > <https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra…> > ), so I am considering an update to a newer LTS version. > However I don’t find which are the next LTS version and for how much > time they will be maintained. > Thanks in advance. > Regards, > Matteo > >

4 years, 12 months

1
0
0 0

Re: [mbed-tls] Mbed TLS: long term support versions

by Dave Rodgman

Hi Matteo, We expect to release an LTS later this year. It’s likely to be 2.27, and very likely will be supported for the usual LTS period of 3 years. So if you are considering updating to a new LTS, you could use 2.26 for prototyping in the short term until the LTS becomes available. The upcoming LTS will be API-compatible with 2.26. Hope this helps, Dave From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of "matteo.cogi--- via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org> Reply to: "matteo.cogi(a)alice.it" <matteo.cogi(a)alice.it> Date: Tuesday, 27 July 2021 at 07:44 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Mbed TLS: long term support versions Dear all, I wish to know which are the future LTS (Long Term Support) versions for Mbed TLS. In these last years I have been working with the 2.16.x, but I read it will be maintained until at least the end of 2021 ( https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra… ), so I am considering an update to a newer LTS version. However I don’t find which are the next LTS version and for how much time they will be maintained. Thanks in advance. Regards, Matteo

4 years, 12 months

1
0
0 0

Mbed TLS: long term support versions

by matteo.cogi＠alice.it

Dear all, I wish to know which are the future LTS (Long Term Support) versions for Mbed TLS. In these last years I have been working with the 2.16.x, but I read it will be maintained until at least the end of 2021 ( https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra… <https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra…> ), so I am considering an update to a newer LTS version. However I don’t find which are the next LTS version and for how much time they will be maintained. Thanks in advance. Regards, Matteo

5 years

1
0
0 0

Re: [mbed-tls] May I know why SHA224 is mandatory with SH256?

by Gilles Peskine

Hello, Mbed TLS has never supported a build with SHA-256 but not SHA-224. In Mbed TLS 2.x, enabling MBEDTLS_SHA256_C enables both SHA-256 and SHA-224. Likewise, MBEDTLS_SHA512_C enables both SHA-512 and SHA-384. The reason for this design is that SHA-256 and SHA-224 have essentially the same code but different constants, and likewise for SHA-512 and SHA-384. What changed in Mbed TLS 3.0 is that there are now separate configuration options for each of the four SHA2 variants. It is not possible yet to enable SHA-384 without SHA-512, SHA-224 without SHA-256 or SHA-256 without SHA-224. These are implementation limitations due to missing #ifdef in various places. We expect to lift these limitations in one of the next 3.x releases. Best regards, -- Gilles Peskine Mbed TLS developer On 19/07/2021 14:50, David Hu via mbed-tls wrote: > > Hi, > > ï¿½ > > It seems that SHA224 is mandatory if SHA256 is selected, in Mbed TLS > latest version, according to this new check below: > > ï¿½ > > #if defined(MBEDTLS_SHA256_C) && !defined(MBEDTLS_SHA224_C) > > #error "MBEDTLS_SHA256_C defined without MBEDTLS_SHA224_C" > > #endif > > ï¿½ > > May I know why SHA224 must be enabled with SHA256? > > Could you please point me to any reference/document? > > ï¿½ > > Best regards, > > Hu Ziji > >

5 years

2
3
0 0

Re: [mbed-tls] How to setup config.h to make memory_buffer_alloc_init() thread-safe?

by Shariful Alam

Hi Gilles, Thank you very much, for your reply. Sorry to bother you again. I am trying to follow your instructions. I have a question regarding your suggestions. You said "applications call mbedtls_memory_buffer_alloc_init() in the startup code of the initial thread, before creating other threads. The alloc/free functions are thread-safe, but the initialization and deinitialization functions aren't." I'm a little confused here. Say, if I call mbedtls_memory_buffer_alloc_init() with a buffer in the main thread, how did all other threads use this memory (or how do all the threads know which memory block to use)? After calling mbedtls_memory_buffer_alloc_init() in the main thread, I can get the address of the buffer and pass it to the threads, do I have to call mbedtls_memory_buffer_alloc_init() again inside each thread? Thanks, Shariful On Mon, Jul 19, 2021 at 3:48 AM Gilles Peskine via mbed-tls < mbed-tls(a)lists.trustedfirmware.org> wrote: > Hi Shariful, > > First, please note that the library called PolarSSL with functions like > rsa_private() and memory_buffer_alloc_init() has not been supported for > several years. You should upgrade to Mbed TLS, with functions like > mbedtls_rsa_private() and mbedtls_memory_buffer_alloc_init(). That being > said, the memory_buffer_alloc module works in the same way. > > Normally, applications call mbedtls_memory_buffer_alloc_init() in the > startup code of the initial thread, before creating other threads. The > alloc/free functions are thread-safe, but the initialization and > deinitialization functions aren't. If you must call > mbedtls_memory_buffer_alloc_init() after creating other threads, make > sure that no thread calls mbedtls_calloc until > mbedtls_memory_buffer_alloc_init() has returned. > > The same principle applies to other parts of Mbed TLS that are > thread-safe. For example, only the RSA operations (encryption, > decryption, signature, verification, and also the low-level functions > mbedtls_rsa_public() and mbedtls_rsa_private()) are protected. So you > must finish setting up the RSA key inside one thread before you pass a > pointer to other threads. Similarly, only mbedtls_xxx_drbg_random() is > thread-safe, and the RNG setup (including mbedtls_xxx_drgb_seed()) > should be done as part of the initial application startup. > > Finally, note that mbedtls_rsa_private() alone cannot decrypt a message: > all it does it to apply the private key operation. To decrypt a simple > message encrypted with RSA-OAEP, call mbedtls_rsa_rsaes_oaep_decrypt() > or mbedtls_rsa_pkcs1_decrypt() with a key set up for > MBEDTLS_RSA_PKCS_V21 encoding. To use the legacy PKCS#1v1.5 mechanism, > call mbedtls_rsa_rsaes_pkcs1_v15_decrypt() or > mbedtls_rsa_pkcs1_decrypt() with a key set up for .MBEDTLS_RSA_PKCS_V15. > To decrypt a message using a RSA FDH hybrid scheme, you do need to call > mbedtls_rsa_private() since Mbed TLS doesn't support it natively, but > what this gives you is the intermediate secret from which you then need > to derive a symmetric key, not the message itself. > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > On 18/07/2021 07:16, Shariful Alam via mbed-tls wrote: > > Hello, > > I have a simple example code to decrypt an encrypted message using > > *rsa_private()*. I use *memory_buffer_alloc_init(), *in order to use > > a static memory for the computation. I want to run my code > > concurrently. My code works with a single pthread. However, when I try > > to run more than one thread my program fails to decrypt. > > > > ** I check the same code without *memory_buffer_alloc_init(), *it > > works concurrently, without any issues at all. > > > > Therefore, I believe, the issue that I'm facing is coming from the use > > of static memory(e.g. *memory_buffer_alloc_init()*). The documentation > > of memorry_buffer_alloc.h shows, > > > > /** > > > > * \brief Initialize use of stack-based memory allocator. > > > > * The stack-based allocator does memory management > > inside the > > > > * presented buffer and does not call malloc() and free(). > > > > * It sets the global polarssl_malloc() and > > polarssl_free() pointers > > > > * to its own functions. > > > > * (Provided polarssl_malloc() and polarssl_free() are > > thread-safe if > > > > * POLARSSL_THREADING_C is defined) > > > > * > > > > * \note This code is not optimized and provides a > straight-forward > > > > * implementation of a stack-based memory allocator. > > > > * > > > > * \param buf buffer to use as heap > > > > * \param len size of the buffer > > > > * > > > > * \return 0 if successful > > > > */ > > > > > > So, I added the following configuration to the *config.h* file > > > > 1. #define POLARSSL_THREADING_PTHREAD > > 2. #define POLARSSL_THREADING_C > > > > But I'm still getting errors while decrypting. Any help on how to fix > > this? or what else should I add into the config.h file to > > make *memory_buffer_alloc_init() *thread-safe? Here is my sample > > code: https://pastebin.com/uyW3vknt <https://pastebin.com/uyW3vknt> > > > > Thanks, > > Shariful > > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls >

5 years

2
1
0 0

May I know why SHA224 is mandatory with SH256?

by David Hu

Hi, It seems that SHA224 is mandatory if SHA256 is selected, in Mbed TLS latest version, according to this new check below: #if defined(MBEDTLS_SHA256_C) && !defined(MBEDTLS_SHA224_C) #error "MBEDTLS_SHA256_C defined without MBEDTLS_SHA224_C" #endif May I know why SHA224 must be enabled with SHA256? Could you please point me to any reference/document? Best regards, Hu Ziji

5 years

1
0
0 0

Re: [mbed-tls] How to setup config.h to make memory_buffer_alloc_init() thread-safe?

by Gilles Peskine

Hi Shariful, First, please note that the library called PolarSSL with functions like rsa_private() and memory_buffer_alloc_init() has not been supported for several years. You should upgrade to Mbed TLS, with functions like mbedtls_rsa_private() and mbedtls_memory_buffer_alloc_init(). That being said, the memory_buffer_alloc module works in the same way. Normally, applications call mbedtls_memory_buffer_alloc_init() in the startup code of the initial thread, before creating other threads. The alloc/free functions are thread-safe, but the initialization and deinitialization functions aren't. If you must call mbedtls_memory_buffer_alloc_init() after creating other threads, make sure that no thread calls mbedtls_calloc until mbedtls_memory_buffer_alloc_init() has returned. The same principle applies to other parts of Mbed TLS that are thread-safe. For example, only the RSA operations (encryption, decryption, signature, verification, and also the low-level functions mbedtls_rsa_public() and mbedtls_rsa_private()) are protected. So you must finish setting up the RSA key inside one thread before you pass a pointer to other threads. Similarly, only mbedtls_xxx_drbg_random() is thread-safe, and the RNG setup (including mbedtls_xxx_drgb_seed()) should be done as part of the initial application startup. Finally, note that mbedtls_rsa_private() alone cannot decrypt a message: all it does it to apply the private key operation. To decrypt a simple message encrypted with RSA-OAEP, call mbedtls_rsa_rsaes_oaep_decrypt() or mbedtls_rsa_pkcs1_decrypt() with a key set up for MBEDTLS_RSA_PKCS_V21 encoding. To use the legacy PKCS#1v1.5 mechanism, call mbedtls_rsa_rsaes_pkcs1_v15_decrypt() or mbedtls_rsa_pkcs1_decrypt() with a key set up for .MBEDTLS_RSA_PKCS_V15. To decrypt a message using a RSA FDH hybrid scheme, you do need to call mbedtls_rsa_private() since Mbed TLS doesn't support it natively, but what this gives you is the intermediate secret from which you then need to derive a symmetric key, not the message itself. Best regards, -- Gilles Peskine Mbed TLS developer On 18/07/2021 07:16, Shariful Alam via mbed-tls wrote: > Hello, > I have a simple example code to decrypt an encrypted message using > *rsa_private()*. I use *memory_buffer_alloc_init(), *in order to use > a static memory for the computation. I want to run my code > concurrently. My code works with a single pthread. However, when I try > to run more than one thread my program fails to decrypt. > > ** I check the same code without *memory_buffer_alloc_init(), *it > works concurrently, without any issues at all. > > Therefore, I believe, the issue that I'm facing is coming from the use > of static memory(e.g. *memory_buffer_alloc_init()*). The documentation > of memorry_buffer_alloc.h shows, > > /** > > * \brief Initialize use of stack-based memory allocator. > > * The stack-based allocator does memory management > inside the > > * presented buffer and does not call malloc() and free(). > > * It sets the global polarssl_malloc() and > polarssl_free() pointers > > * to its own functions. > > * (Provided polarssl_malloc() and polarssl_free() are > thread-safe if > > * POLARSSL_THREADING_C is defined) > > * > > * \note This code is not optimized and provides a straight-forward > > * implementation of a stack-based memory allocator. > > * > > * \param buf buffer to use as heap > > * \param len size of the buffer > > * > > * \return 0 if successful > > */ > > > So, I added the following configuration to the *config.h* file > > 1. #define POLARSSL_THREADING_PTHREAD > 2. #define POLARSSL_THREADING_C > > But I'm still getting errors while decrypting. Any help on how to fix > this? or what else should I add into the config.h file to > make *memory_buffer_alloc_init() *thread-safe? Here is my sample > code: https://pastebin.com/uyW3vknt <https://pastebin.com/uyW3vknt> > > Thanks, > Shariful >

5 years

1
0
0 0

How to setup config.h to make memory_buffer_alloc_init() thread-safe?

by Shariful Alam

Hello, I have a simple example code to decrypt an encrypted message using *rsa_private()*. I use *memory_buffer_alloc_init(), *in order to use a static memory for the computation. I want to run my code concurrently. My code works with a single pthread. However, when I try to run more than one thread my program fails to decrypt. ** I check the same code without *memory_buffer_alloc_init(), *it works concurrently, without any issues at all. Therefore, I believe, the issue that I'm facing is coming from the use of static memory(e.g. *memory_buffer_alloc_init()*). The documentation of memorry_buffer_alloc.h shows, /** * \brief Initialize use of stack-based memory allocator. * The stack-based allocator does memory management inside the * presented buffer and does not call malloc() and free(). * It sets the global polarssl_malloc() and polarssl_free() > pointers * to its own functions. * (Provided polarssl_malloc() and polarssl_free() are thread-safe > if * POLARSSL_THREADING_C is defined) * * \note This code is not optimized and provides a straight-forward * implementation of a stack-based memory allocator. * * \param buf buffer to use as heap * \param len size of the buffer * * \return 0 if successful */ So, I added the following configuration to the *config.h* file 1. #define POLARSSL_THREADING_PTHREAD 2. #define POLARSSL_THREADING_C But I'm still getting errors while decrypting. Any help on how to fix this? or what else should I add into the config.h file to make *memory_buffer_alloc_init() *thread-safe? Here is my sample code: https://pastebin.com/uyW3vknt Thanks, Shariful

5 years

1
1
0 0

question about sslv3 alert certificate unknown

by Ron Eggler

Hi, I'm working on a client application that will connect to an FTPS server (vsftpd) to download files. Now, I have ca-cert, cert and key files all setup to work with curl like: curl -3 -k -v --ftp-ssl --tlsv1.2 --ftp-ssl-reqd --ftp-pasv --verbose \ --ssl \ --cert ./en-cert.pem \ --cert-type PEM \ --key ./en-cert.key \ --key-type PEM \ --cacert ./ca-cert \ ftp://user:pass@10.10.100.1/test.txt -O Now, I use the same cert, key & ca-cert with mbedtls but am unable to handshake, mbedtls_ssl_handshake() keeps giving me an error, what is done in order: - init cert, ca-cert, key, entropy, drbg, ssl, config - parse ca-cert, cert & key - seed RNG - mbedtls_ctr_drbg_seed with mbedtls_hardware_poll - set config defaults MBEDTLS_SSL_IS_CLIENT, MBEDTLS_SSL_TRANSPORT_STREAM, MBEDTLS_SSL_PRESET_DEFAULT - mbedtls_ssl_conf_ca_chain - mbedtls_ssl_conf_rng with mbedtls_ctr_drbg_random - mbedtls_ssl_conf_dbg - mbedtls_ssl_conf_own_cert - mbedtls_ssl_setup - mbedtls_ssl_set_bio - mbedtls_ssl_handshake which up to the handshake all seems to go through without any issues. When I look at it with wireshark, I see something like: Response: 234 Proceed with negotiation. Request:looks like the certificate jumbled up Response 500 OOPS: Response :SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown Any hints on how I best go about troubleshooting this? I have confirmed that ca-cert, cert & key are identical to the ones that are used for the above curl command. Thanks,

5 years

1
0
0 0

Re: [mbed-tls] Question about dynamic linking, versioning and API/ABI stability

by Janos Follath

Hi, Semantic versioning applies only to API compatibility but not for ABI. When we break the ABI we increase the SO version for that part of the library and this is how linux distributions normally track our ABI compatibility. Additionally, we try very hard not to break ABI at all in LTS versions. You can find a detailed description what Mbed TLS promises regarding API/ABI compatibility: https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md Kind regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Hugues De Valon via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Date: Wednesday, 14 July 2021 at 17:09 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Question about dynamic linking, versioning and API/ABI stability Hello, We are using Mbed Crypto in our Parsec project through the psa-crypto Rust crate (https://github.com/parallaxsecond/rust-psa-crypto). We currently have Mbed Crypto through Mbed TLS 2.25.0 which we build statically from scratch by default. We also offer the option to dynamically link with an Mbed Crypto library available on the system. Ideally, this would offer an easy and simple way to patch bug fixes without having to recompile everything. However, as we observed API (and probably ABI) breaking changes over the past versions of Mbed TLS we were wondering if this (dynamic linking) was a model we should promote at all. Is there a semantic versioning process currently applied in Mbed TLS? If we use Mbed TLS 3.0.0 in our crate, can we be sure than 3.x.y versions won’t contain any API/ABI breaking changes or is there nothing of the sort? I believe that Mbed Crypto is catching up to be fully compliant with PSA Crypto 1.0.1. Once that will be the case, will its API/ABI be stable and follow the PSA Crypto semantic versioning? It might be that the good solution is that we shouldn’t dynamically link with Mbed Crypto but always compile it from scratch as we do by default. I am just sending this email so that we follow the good approach! Kind regards, Hugues

5 years

2
2
0 0

Question about dynamic linking, versioning and API/ABI stability

by Hugues De Valon

Hello, We are using Mbed Crypto in our Parsec project through the psa-crypto Rust crate (https://github.com/parallaxsecond/rust-psa-crypto). We currently have Mbed Crypto through Mbed TLS 2.25.0 which we build statically from scratch by default. We also offer the option to dynamically link with an Mbed Crypto library available on the system. Ideally, this would offer an easy and simple way to patch bug fixes without having to recompile everything. However, as we observed API (and probably ABI) breaking changes over the past versions of Mbed TLS we were wondering if this (dynamic linking) was a model we should promote at all. Is there a semantic versioning process currently applied in Mbed TLS? If we use Mbed TLS 3.0.0 in our crate, can we be sure than 3.x.y versions won't contain any API/ABI breaking changes or is there nothing of the sort? I believe that Mbed Crypto is catching up to be fully compliant with PSA Crypto 1.0.1. Once that will be the case, will its API/ABI be stable and follow the PSA Crypto semantic versioning? It might be that the good solution is that we shouldn't dynamically link with Mbed Crypto but always compile it from scratch as we do by default. I am just sending this email so that we follow the good approach! Kind regards, Hugues

5 years

1
0
0 0

serial communication in FTP

by Sunil Jain

Hello, we are using the mbed-tls for secure communication for FTP. FTP server is handling the client hello serially one at a time, one communication is blocking other clients to communicate. What could be the reason and how to solve this issue. -- Thanks and Regards, Sunil Jain

5 years

1
0
0 0

Mbed TLS: Release of Mbed TLS 3.0.0, 2.27.0, and 2.16.11

by Dave Rodgman

Hi Mbed TLS users, We are pleased to announce the release of Mbed TLS versions 3.0.0, 2.27.0 and 2.16.11. These releases of Mbed TLS address several security issues, and provide bug fixes and enhancements. Mbed TLS 3.0.0 also brings many API-breaking changes. Full details, including security advisories, are available in the release notes: https://github.com/ARMmbed/mbedtls/releases/tag/v3.0.0 https://github.com/ARMmbed/mbedtls/releases/tag/v2.27.0 https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.11 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Dave Rodgman

5 years

1
0
0 0

Mbed TLS: Release of Mbed TLS 3.0.0, 2.27.0, and 2.16.11

by Dave Rodgman

Hi Mbed TLS users, We are pleased to announce the release of Mbed TLS versions 3.0.0, 2.27.0 and 2.16.11. These releases of Mbed TLS address several security issues, and provide bug fixes and enhancements. Mbed TLS 3.0.0 also brings many API-breaking changes. Full details, including security advisories, are available in the release notes: https://github.com/ARMmbed/mbedtls/releases/tag/v3.0.0 https://github.com/ARMmbed/mbedtls/releases/tag/v2.27.0 https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.11 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Dave Rodgman

5 years

1
0
0 0

Re: [mbed-tls] mbedtls_x509_crt_parse returned -0x2180

by Danny Backx

Gilles, Thanks for getting me to try to read DER files. There must definitely be something wrong in that area. I am speficying support for PEM in the build but reading DER gets me past that error. Searching further :-) Again, thanks Danny On 05/07/2021 20:27, Gilles Peskine via mbed-tls wrote: > Hello, > > The first thing when you see an unexpected error code is to look up the > corresponding error message. Mbed TLS comes with a utility for that: > > programs/util/strerror 0x2180 > Last error was: -0x2180 - X509 - The CRT/CRL/CSR format is invalid, > e.g. different type expected > > You can also search the error code in the source code: > > grep 0x2180 include/mbedtls/*.h > include/mbedtls/x509.h:#define > MBEDTLS_ERR_X509_INVALID_FORMAT -0x2180 /**< The > CRT/CRL/CSR format is invalid, e.g. different type expected. */ > > At first glance it looks like there's only one case for which CRT > parsing return MBEDTLS_ERR_X509_INVALID_FORMAT as opposed to > (MBEDTLS_ERR_X509_INVALID_FORMAT + low_level_error_code), and that's if > the certificate doesn't parse like a DER format at the top level. A > plausible reason for that is that the certificate is in PEM format and > your build has PEM support turned off. If that's the case, convert the > certifcate to DER when you copy it to the device. You can use the Mbed > TLS utility programs/util/pem2der for that. > > Best regards, > -- Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info

5 years

1
0
0 0

SHA NI support in mbedtls

by Lu, Jingdong

Hi, mbedtls experts I note that there is AES NI support (aesni.c) on x86 platform. I'm wondering why there is no SHA NI support for SHA1 and SHA256? How can I get SHA NI support? Should I choose another crypto library? Thanks, Jingdong

5 years

1
0
0 0

Re: [mbed-tls] mbedtls_x509_crt_parse returned -0x2180

by Gilles Peskine

Hello, The first thing when you see an unexpected error code is to look up the corresponding error message. Mbed TLS comes with a utility for that: programs/util/strerror 0x2180 Last error was: -0x2180 - X509 - The CRT/CRL/CSR format is invalid, e.g. different type expected You can also search the error code in the source code: grep 0x2180 include/mbedtls/*.h include/mbedtls/x509.h:#define MBEDTLS_ERR_X509_INVALID_FORMAT -0x2180 /**< The CRT/CRL/CSR format is invalid, e.g. different type expected. */ At first glance it looks like there's only one case for which CRT parsing return MBEDTLS_ERR_X509_INVALID_FORMAT as opposed to (MBEDTLS_ERR_X509_INVALID_FORMAT + low_level_error_code), and that's if the certificate doesn't parse like a DER format at the top level. A plausible reason for that is that the certificate is in PEM format and your build has PEM support turned off. If that's the case, convert the certifcate to DER when you copy it to the device. You can use the Mbed TLS utility programs/util/pem2der for that. Best regards, -- Gilles Peskine Mbed TLS developer On 05/07/2021 18:10, Danny Backx via mbed-tls wrote: > > Hi, > > I must be missing something obvious but my code (on an ESP32) fails to > accept an incoming connection. > > I tried the same certificate on an ESP32 sample, and it appears to > work there. > > Does anyone have a clue where to look next ? > > Danny > > I (16:06:51.481) esp_https_server: performing session handshake > E (16:06:51.483) x509_crt: x509_crt_parse_der_core -> 0x2180 > E (16:06:51.484) esp_tls_mbedtls: set_pki_context: public_cert > 0x3ffdb924, len 5750 -> ret 0x2180 > E (16:06:51.493) esp-tls-mbedtls: mbedtls_x509_crt_parse returned -0x2180 > E (16:06:51.501) esp-tls-mbedtls: Failed to set server pki context > E (16:06:51.508) esp-tls-mbedtls: Failed to set server configurations > E (16:06:51.515) esp-tls-mbedtls: create_ssl_handle failed > E (16:06:51.521) esp_https_server: esp_tls_create_server_session failed > W (16:06:51.528) httpd: httpd_accept_conn: session creation failed > W (16:06:51.538) httpd: httpd_server: error accepting new connection > > -- > Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info >

5 years

1
0
0 0

mbedtls_x509_crt_parse returned -0x2180

by Danny Backx

Hi, I must be missing something obvious but my code (on an ESP32) fails to accept an incoming connection. I tried the same certificate on an ESP32 sample, and it appears to work there. Does anyone have a clue where to look next ? Danny I (16:06:51.481) esp_https_server: performing session handshake E (16:06:51.483) x509_crt: x509_crt_parse_der_core -> 0x2180 E (16:06:51.484) esp_tls_mbedtls: set_pki_context: public_cert 0x3ffdb924, len 5750 -> ret 0x2180 E (16:06:51.493) esp-tls-mbedtls: mbedtls_x509_crt_parse returned -0x2180 E (16:06:51.501) esp-tls-mbedtls: Failed to set server pki context E (16:06:51.508) esp-tls-mbedtls: Failed to set server configurations E (16:06:51.515) esp-tls-mbedtls: create_ssl_handle failed E (16:06:51.521) esp_https_server: esp_tls_create_server_session failed W (16:06:51.528) httpd: httpd_accept_conn: session creation failed W (16:06:51.538) httpd: httpd_server: error accepting new connection -- Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info

5 years

1
0
0 0

Hardware CCM decrypt failure

by Navin Reddy

Hello everyone, I am currently evaluating SSL with a local server and an STM32 device. I'm unable to figure out why the decryption fails with CCM as the cipher suite. FYI: I am using MbedTLS *v2.14.1.* *Setup*: I'm using *x86 local server* with *STM32* device as a client. Here is what happens- 1. Software CCM implementation on the client: When I use the *software* implementation of the CCM. Handshake and decryption is *successful*. Therefore, I can stream the data from STM32 and read it on the local server. 2. Hardware CCM implementation with MBEDTLS_CCM_ALT: I have used ccm_alt.c provided from STM32Cube v1.9.0. Here, the handshake is successful. But *decrypting* the message *fails*. The errors are: ssl_decrypt_buf() returned -29056 (-0x7180) mbedtls_ssl_read_record() returned -29056 (-0x7180) Checks performed: - Same certificates are used for SW and HW implementations. - CCM self test returns '0' for both HW and SW CCM implementations. - I have reserved enough heap, no memory issues. Please find all the necessary data in the attachment provided. I have added the logs from the server and the client. I have added the certificates and the code files as well. It would be of great help if somebody could point at what might be going wrong. Thank you! Best regards, Navin

5 years

1
0
0 0

Re: [mbed-tls] Is the a version that can use the EdDSA signature algorithm currently?

by Janos Follath

Hi Shudong, Mbed TLS currently does not provide EdDSA. The contribution by @aurel32 is a first step in this direction. The work leading up to a fully functional EdDSA implementation is tracked here: https://github.com/ARMmbed/mbedtls/projects/2#column-11150355 Kind regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Shudong Zhang via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Date: Wednesday, 30 June 2021 at 07:28 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Is the a version that can use the EdDSA signature algorithm currently? Hello, I want to use EdDSA signature algorithm, but I did’t find API for it in 2.26.0.Then I searched in the issue of Github and I found @aurel32 contributed some code about ed25519.But I am still not sure whether there are any versions under development that provide interface functions for EdDSA signature algorithm. Can someone help me answer my question? Thanks and kind regards, Shudong

5 years

1
0
0 0

Is the a version that can use the EdDSA signature algorithm currently?

by Shudong Zhang

Hello, I want to use EdDSA signature algorithm, but I did’t find API for it in 2.26.0.Then I searched in the issue of Github and I found @aurel32 contributed some code about ed25519.But I am still not sure whether there are any versions under development that provide interface functions for EdDSA signature algorithm. Can someone help me answer my question? Thanks and kind regards, Shudong

5 years

1
0
0 0

How to include alternate name in CSR

by Danny Backx

Hi, I have an ACME client library for esp32, and I try to extend it to support multiple host names. First step is to include alternate names in the CSR. After I tried the ARMmbed issues forum, I was pointed to this list. My code is in http://svn.code.sf.net/p/esp32-acme-client/code/trunk/libraries/acmeclient/… <http://svn.code.sf.net/p/esp32-acme-client/code/trunk/libraries/acmeclient/…> (see function Acme::CreateAltUrlList) , the function below is an attempt to do what I described, but doesn't work. Can anyone help ? Danny int Acme::CreateAltUrlList(mbedtls_x509write_csr req) { int l = 20; int ret; for (int i=0; alt_urls[i]; i++) { l += strlen(alt_urls[i]) + 20; } unsigned char *buf = (unsigned char *)malloc(l), *p = buf + l; int len = 0; for (int i=0; alt_urls[i]; i++) { MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_raw_buffer(&p, buf, (const unsigned char *)alt_urls[i], strlen(alt_urls[i]))); MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_len(&p, buf, strlen(alt_urls[i]))); MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_tag(&p, buf, MBEDTLS_ASN1_CONTEXT_SPECIFIC | 2)); } MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_len(&p, buf, len)); MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_tag(&p, buf, MBEDTLS_ASN1_CONSTRUCTED | MBEDTLS_ASN1_SEQUENCE)); if ((ret = mbedtls_x509write_csr_set_extension(&req, MBEDTLS_OID_SUBJECT_ALT_NAME, MBEDTLS_OID_SIZE(MBEDTLS_OID_SUBJECT_ALT_NAME), (const unsigned char *)p, len)) != 0) { char errbuf[80]; mbedtls_strerror(ret, errbuf, sizeof(errbuf)); ESP_LOGE(acme_tag, "%s: mbedtls_x509write_csr_set_extension failed %s (0x%04x)", *__FUNCTION__*, errbuf, -ret); } free(buf); ESP_LOGD(acme_tag, "%s: ret %d", *__FUNCTION*__, ret); return ret; } -- Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info

5 years

1
0
0 0

Re: [mbed-tls] List archive?

by Shebu Varghese Kuriakose

Hi David, Archive can be found here https://lists.trustedfirmware.org/pipermail/mbed-tls/ https://lists.trustedfirmware.org/pipermail/psa-crypto/ Regards, Shebu -----Original Message----- From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of David Higton via mbed-tls Sent: Friday, June 25, 2021 2:51 PM To: mbed-tls(a)lists.trustedfirmware.org Subject: [mbed-tls] List archive? Hi everybody, I've just joined the list. The first thing I did was to try to find an archive of list postings, but I haven't found one. Is there one, and, if so, where do I find it? The information may have been staring me in the face; if that's the case, I apologise. David -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

5 years, 1 month

1
1
0 0

List archive?

by David Higton

Hi everybody, I've just joined the list. The first thing I did was to try to find an archive of list postings, but I haven't found one. Is there one, and, if so, where do I find it? The information may have been staring me in the face; if that's the case, I apologise. David

5 years, 1 month

1
0
0 0

Re: [mbed-tls] Is TCP integrated in mbed-TLS?

by Janos Follath

Hi Anasasija, Mbed TLS is entirely agnostic of the communication channel or protocol. You can configure it to use any underlying layer, like TCP, UDP or even just a local buffer. That said, we have a module that makes it more convenient to use Mbed TLS with TCP (or UDP) on common platforms: https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/net_soc… You can see an example for using the module in several sample applications, for example: https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_client… and https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_server… Kind regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of 1637062--- via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Date: Friday, 25 June 2021 at 09:27 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Is TCP integrated in mbed-TLS? Hello, I am a Student and for my bachelor thesis I am working on a tool that is able to detect whether a server is vulnerable regarding Bleichenbacher's attack or not, testing multiple side channels. For this I am looking for a TLS implementation that has the TCP protocol integrated and generates the TCP messages. I was wondering if mbed-tls has the TCP integrated in the implementation or not. If so, I could make use of this information, too. Thanks and kind regards, Anastasija -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

5 years, 1 month

1
0
0 0

Re: [mbed-tls] mbed-tls Digest, Vol 16, Issue 12

by Janos Follath

Hi Lijin, It still can be the endianness of the keys. If the key is reversed, there won’t be any discernible pattern or relationship between the derived secrets. Regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of T V LIJIN (EXT) via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Date: Friday, 25 June 2021 at 09:15 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] mbed-tls Digest, Vol 16, Issue 12 Hello, We couldn't see word swap in the output from both the end. Issue doesn't look related to the endianness. Could you please confirm that the code used for ECDHE key exchange is proper? SHARED_SECRET (Computed on Client): 11 36 F7 DB 2B 14 BB 86 1C A0 FC DF 6D 4D 17 70 BE 4F D8 58 C2 11 67 10 42 D7 47 EB 14 4B 10 5E SHARED_SECRET(Computed on Sever): c6 96 d9 f0 ec 37 be 9e 1a 60 a4 5f 88 f2 13 d3 bb 98 15 3f 3b d9 81 37 c6 10 12 85 e5 8b 49 16 Thanks, LIJIN T V ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of mbed-tls-request(a)lists.trustedfirmware.org <mbed-tls-request(a)lists.trustedfirmware.org> Sent: Friday, June 25, 2021 4:52 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: mbed-tls Digest, Vol 16, Issue 12 This message is from an external sender. Be cautious, especially with links and attachments. Send mbed-tls mailing list submissions to mbed-tls(a)lists.trustedfirmware.org To subscribe or unsubscribe via the World Wide Web, visit https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… or, 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. ECDHE Shared Secret is computed differently (T V LIJIN (EXT)) 2. Re: ECDHE Shared Secret is computed differently (Brian D.) 3. How does the bignum.c works? (Shariful Alam) ---------------------------------------------------------------------- Message: 1 Date: Thu, 24 Jun 2021 13:35:03 +0000 From: "T V LIJIN (EXT)" <lijin.tv(a)kone.com> To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] ECDHE Shared Secret is computed differently Message-ID: <AS8PR07MB8006A77D2451AD93FAFDA3D8FE079(a)AS8PR07MB8006.eurprd07.prod.outlook.com> Content-Type: text/plain; charset="iso-8859-1" Hello , We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS] Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends. We have tested the same source code on Visual studio and found working. I have attached the source files Could you please comment on why the computed shared secret are different on both the ends? Thanks, LIJIN T V

5 years, 1 month

1
0
0 0

Is TCP integrated in mbed-TLS?

by 1637062＠uni-wuppertal.de

Hello, I am a Student and for my bachelor thesis I am working on a tool that is able to detect whether a server is vulnerable regarding Bleichenbacher's attack or not, testing multiple side channels. For this I am looking for a TLS implementation that has the TCP protocol integrated and generates the TCP messages. I was wondering if mbed-tls has the TCP integrated in the implementation or not. If so, I could make use of this information, too. Thanks and kind regards, Anastasija

5 years, 1 month

1
0
0 0

Re: [mbed-tls] mbed-tls Digest, Vol 16, Issue 12

by T V LIJIN (EXT)

Hello, We couldn't see word swap in the output from both the end. Issue doesn't look related to the endianness. Could you please confirm that the code used for ECDHE key exchange is proper? SHARED_SECRET (Computed on Client): 11 36 F7 DB 2B 14 BB 86 1C A0 FC DF 6D 4D 17 70 BE 4F D8 58 C2 11 67 10 42 D7 47 EB 14 4B 10 5E SHARED_SECRET(Computed on Sever): c6 96 d9 f0 ec 37 be 9e 1a 60 a4 5f 88 f2 13 d3 bb 98 15 3f 3b d9 81 37 c6 10 12 85 e5 8b 49 16 Thanks, LIJIN T V ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of mbed-tls-request(a)lists.trustedfirmware.org <mbed-tls-request(a)lists.trustedfirmware.org> Sent: Friday, June 25, 2021 4:52 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: mbed-tls Digest, Vol 16, Issue 12 This message is from an external sender. Be cautious, especially with links and attachments. Send mbed-tls mailing list submissions to mbed-tls(a)lists.trustedfirmware.org To subscribe or unsubscribe via the World Wide Web, visit https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… or, 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. ECDHE Shared Secret is computed differently (T V LIJIN (EXT)) 2. Re: ECDHE Shared Secret is computed differently (Brian D.) 3. How does the bignum.c works? (Shariful Alam) ---------------------------------------------------------------------- Message: 1 Date: Thu, 24 Jun 2021 13:35:03 +0000 From: "T V LIJIN (EXT)" <lijin.tv(a)kone.com> To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] ECDHE Shared Secret is computed differently Message-ID: <AS8PR07MB8006A77D2451AD93FAFDA3D8FE079(a)AS8PR07MB8006.eurprd07.prod.outlook.com> Content-Type: text/plain; charset="iso-8859-1" Hello , We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS] Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends. We have tested the same source code on Visual studio and found working. I have attached the source files Could you please comment on why the computed shared secret are different on both the ends? Thanks, LIJIN T V

5 years, 1 month

1
0
0 0

How does the bignum.c works?

by Shariful Alam

Hello, Can someone please briefly explain how does the bignum.c library works in terms of RSA? I understand that this is too broad a question to ask. but If someone can briefly explain the basic working mechanism it will be a great help. Thanks, Shariful

5 years, 1 month

1
0
0 0

Re: [mbed-tls] ECDHE Shared Secret is computed differently

by Brian D.

Hi Linjin, I am not part of the mbed-tls staff but I developed a lot with mbed library and I had your same problem. Try to check the byte order, I had issues when computing the shared secret because I had the little endian from the other side but mbed uses big endian. Try to do a quick test and this could resolve your problem, let me know! Bye, Brian 24 giu 2021, 15:35 da mbed-tls(a)lists.trustedfirmware.org: > Hello , > We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS] > Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends. > We have tested the same source code on Visual studio and found working. > I have attached the source files > > Could you please comment on why the computed shared secret are different on both the ends? > > Thanks, > LIJIN T V >

5 years, 1 month

1
0
0 0

ECDHE Shared Secret is computed differently

by T V LIJIN (EXT)

Hello , We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS] Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends. We have tested the same source code on Visual studio and found working. I have attached the source files Could you please comment on why the computed shared secret are different on both the ends? Thanks, LIJIN T V

5 years, 1 month

1
0
0 0

Re: [mbed-tls] Please help regarding [ERR ][TLSx]: mbedtls_ssl_handshake() failed: -0x7780 (-30592): SSL

by Gilles Peskine

Hi Victor, Looking through the ciphersuites your client sends, I think you've only enabled ECDHE ciphersuites, not DHE ciphersuites, which makes perfect sense, especially on an embedded device, since DH(E) is a lot slower than ECDH(E) for the same security level. So on the server you need to enable ECDHE ciphersuites. Best regards, -- Gilles Peskine Mbed TLS developer On 09/06/2021 23:03, victor Wolff via mbed-tls wrote: > > Hello > > I am relatively new to mbedTLS, but I'm trying to develop an MQTT > client running on an STM32 board connected to an ESP8266 MCU/WiFi > module. The client should publish messages to a local broker/server > where I am using Mosquitto for that purpose. > I want to test different Cipher suites but when I limiting the Server > to only accept one particle Cipher suite I receive an error from the > server point of view ï¿½1622667145: OpenSSL Error[0]: error:1417A0C1:SSL > routines:tls_post_process_client_hello:*no shared cipher*" > Which I find is strange because when I read through the debug list > presented below it says ï¿½[DBG ][TLSx]: ssl_cli.c:0884: |3| client > hello, add ciphersuite: c02cï¿½. > > ï¿½ > > I ï¿½thinkï¿½ I have enabled the "MBEDTLS_SHA256_C" in the config file > (mbed_lib.json) for the TLSsocket, and the cipher suites I have tested > so far to limit it for is: DHE-RSA-AES128-SHA |AES128-SHA | > DHE-RSA-AES128-SHA256. > > ï¿½ > > Could you please look at the debug list presented below to see if > anything looks suspicious, or if you have any ideas? > because I am truly lost and I am shooting in the dark trying to find > the answer online... > > Thank you sincerely in advance > Best regards Victor > > ï¿½ > > ï¿½ > > --------Debug list -------- > > ï¿½ > > AT< WIFI CONNECTED > > AT< WIFI GOT IP > > AT< > > AT= OK > > AT> AT+CIFSR > > AT< > > AT< AT+CIFSR > > AT< +CIFSR:APIP,"192.168.4.1" > > AT< +CIFSR:APMAC,"da:bf:c0:0d:c5:d8" > > AT= +CIFSR:STAIP,"192.168.10.103" > > AT< > > AT< +CIFSR:STAMAC,"d8:bf:c0:0d:c5:d8" > > AT< > > AT= OK > > Network interface opened successfully. > > ï¿½ > > Connecting to host 192.168.10.165:8883 ... > > Hello > > [INFO][TLSx]: Connecting to 192.168.10.165:8883 > > AT> AT+CIPSTART=0,"TCP","192.168.10.165",8883 > > AT< > > AT< AT+CIPSTART=0,"TCP","192.168.10.165",8883 > > AT< 0,CONNECT > > AT< > > AT= OK > > [INFO][TLSx]: Connected. > > [INFO][TLSx]: Starting the TLS handshake... > > [DBG ][TLSx]: ssl_tls.c:6335: |2| => handshake > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:3279: |2| client state: 0 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2428: |2| <= flush output > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:3279: |2| client state: 1 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2428: |2| <= flush output > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0717: |2| => write client hello > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0754: |3| client hello, max version: [3:3] > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0693: |3| client hello, current time: 14712 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0764: |3| dumping 'client hello, random bytes' > (32 bytes) > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0764: |3| 0000:ï¿½ 00 00 39 78 00 7d 4e 7a c5 43 > 7f d9 5b 0c cd 3fï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > ..9x.}Nz.C..[..? > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0764: |3| 0010:ï¿½ 01 a0 2f 60 8e a5 c1 54 1c 0e > 58 6a a3 da c0 7aï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > ../`...T..Xj...z > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0817: |3| client hello, session id len.: 0 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0818: |3| dumping 'client hello, session id' > (0 bytes) > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c02c > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c030 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0ad > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c024 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c028 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0af > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c02b > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c02f > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0ac > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c023 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c027 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0ae > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c038 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c037 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: 00a9 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0a5 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: 00af > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0a9 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: 00a8 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0a4 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: 00ae > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0a8 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0918: |3| client hello, got 23 ciphersuites > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0949: |3| client hello, compress len.: 1 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0950: |3| client hello, compress alg.: 0 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0071: |3| client hello, adding server name > extension: > 192.168.10ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ .165 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0178: |3| client hello, adding > signature_algorithms extension > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0263: |3| client hello, adding > supported_elliptic_curves extensiï¿½ï¿½ï¿½ï¿½ï¿½ > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½on > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0326: |3| client hello, adding > supported_point_formats extension > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0507: |3| client hello, adding > encrypt_then_mac extension > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0541: |3| client hello, adding > extended_master_secret extension > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0575: |3| client hello, adding session ticket > extension > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:1022: |3| client hello, total extension length: 73 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2701: |2| => write record > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2835: |3| output record: msgtype = 22, version > = [3:1], msglen =ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½164 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| dumping 'output record sent to > network' (169 bytes) > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0000:ï¿½ 16 03 01 00 a4 01 00 00 a0 03 > 03 00 00 39 78 00ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > .............9x. > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0010:ï¿½ 7d 4e 7a c5 43 7f d9 5b 0c cd > 3f 01 a0 2f 60 8eï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > }Nz.C..[..?../`. > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0020:ï¿½ a5 c1 54 1c 0e 58 6a a3 da c0 > 7a 00 00 2e c0 2cï¿½ï¿½ï¿½ï¿½ï¿½ > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½..T..Xj...z...., > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0030:ï¿½ c0 30 c0 ad c0 24 c0 28 c0 af > c0 2b c0 2f c0 acï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > .0...$.(...+./.. > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0040:ï¿½ c0 23 c0 27 c0 ae c0 38 c0 37 > 00 a9 c0 a5 00 afï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > .#.'...8.7...... > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0050:ï¿½ c0 a9 00 a8 c0 a4 00 ae c0 a8 > 00 ff 01 00 00 49ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½...............I > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0060:ï¿½ 00 00 00 13 00 11 00 00 0e 31 > 39 32 2e 31 36 38ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > .........192.168 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0070:ï¿½ 2e 31 30 2e 31 36 35 00 0d 00 > 12 00 10 06 03 06ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > .10.165......... > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0080:ï¿½ 01 05 03 05 01 04 03 04 01 03 > 03 03 01 00 0a 00ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > ................ > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0090:ï¿½ 06 00 04 00 18 00 17 00 0b 00 > 02 01 00 00 16 00ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½................ > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 00a0:ï¿½ 00 00 17 00 00 00 23 00 > 00ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > ......#.. > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2434: |2| message length: 169, out_left: 169 > > ï¿½ > > AT> AT+CIPSEND=0,169 > > AT< > > AT< AT+CIPSEND=0,169 > > AT< > > AT< OK > > AT= > > > [DBG ][TLSx]: ssl_tls.c:2441: |2| ssl->f_send() returned 169 (-0xffffff57) > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2460: |2| <= flush output > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2850: |2| <= write record > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:1049: |2| <= write client hello > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:3279: |2| client state: 2 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2428: |2| <= flush output > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:1410: |2| => parse server hello > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3728: |2| => read record > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2208: |2| => fetch input > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2365: |2| in_left: 0, nb_want: 5 > > ï¿½ > > AT< > > AT< Recv 169 bytes > > AT< > > AT< SEND OK > > AT< > > AT! +IPD > > AT= ,0,7: > > AT< 0,CLOSED > > [DBG ][TLSx]: ssl_tls.c:2389: |2| in_left: 0, nb_want: 5 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:6345: |2| <= handshake > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:6335: |2| => handshake > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:3279: |2| client state: 2 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2428: |2| <= flush output > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:1410: |2| => parse server hello > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3728: |2| => read record > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2208: |2| => fetch input > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2365: |2| in_left: 0, nb_want: 5 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2389: |2| in_left: 0, nb_want: 5 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2391: |2| ssl->f_recv(_timeout)() returned 5 > (-0xfffffffb) > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2403: |2| <= fetch input > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3479: |4| dumping 'input record header' (5 bytes) > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3479: |4| 0000:ï¿½ 15 03 03 00 > 02ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½..... > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3485: |3| input record: msgtype = 21, version > = [3:3], msglen =ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 2 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2208: |2| => fetch input > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2365: |2| in_left: 5, nb_want: 7 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2389: |2| in_left: 5, nb_want: 7 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2391: |2| ssl->f_recv(_timeout)() returned 2 > (-0xfffffffe) > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2403: |2| <= fetch input > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3656: |4| dumping 'input record from network' > (7 bytes) > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3656: |4| 0000:ï¿½ 15 03 03 00 02 02 > 28ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½......( > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3960: |2| got an alert message, type: [2:40] > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3968: |1| is a fatal alert message (msg 40) > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3744: |1| mbedtls_ssl_handle_message_type() > returned -30592 (-0xï¿½ï¿½ï¿½ > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½7780) > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:1416: |1| mbedtls_ssl_read_record() returned > -30592 (-0x7780) > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:6345: |2| <= handshake > > ï¿½ > > [ERR ][TLSx]: mbedtls_ssl_handshake() failed: -0x7780 (-30592): SSL > > AT> AT+CIPCLOSE=0 > > AT< AT+CIPCLOSE=0 > > AT< UNLINK > > AT< > > AT< ERROR > > AT> AT+CIPCLOSE=0 > > AT< AT+CIPCLOSE=0 > > AT< UNLINK > > AT< > > AT< ERROR > > ERROR: rc from TCP connect is -30592 > > [DBG ][TLSx]: ssl_tls.c:7055: |2| => free > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:7120: |2| <= free > > ï¿½ > > AT> AT+CWQAP > > AT< AT+CWQAP > > AT< > > AT= OK > >

5 years, 1 month

1
0
0 0

Re: [mbed-tls] export keys in pkcs8. plain or encrypted

by Gilles Peskine

Hi Andrey, Thank you for your interest in Mbed TLS! In general we welcome contributions to the project. Unfortunately, our limiting factor is bandwidth for review. In 2021 the Mbed TLS team has grown, so we have more time for reviews, but we are still struggling to catch up with the large backlog. There is already an old attempt to add unencrypted PKCS#8 writing support (https://github.com/ARMmbed/mbedtls/issues/1695 <https://github.com/ARMmbed/mbedtls/issues/1695>). There is a long pending request for encrypted PKCS#8 writing support (https://github.com/ARMmbed/mbedtls/issues/1372 <https://github.com/ARMmbed/mbedtls/issues/1372>) but I'm not aware of any prior implementation. We would be glad to have your contribution, but I must be honest and say it might take us several months to get around to it. Best regards, -- Gilles Peskine Mbed TLS developer On 09/06/2021 22:46, Андрей Макаров via mbed-tls wrote: > Recently I used mbedtls library in my working project. In accordance > with the needs of the project, I added some functions to mbedtls for > saving and loading keys in plain and encrypted pem and der forms. > The changes are still raw and should be brought up to pull request > requirements - there are no tests, since the functions tested as part > of a working project which uses mbedtls. I can, over time, finalize > the changes to a pull request, but it will take some time and effort > that you don't want to waste unnecessarily — this will have to be done > at my home time. > If there is an interest for this work, then I will try to do it, but > if few people need it or do not coincide with the general direction of > development of the project, then I would not bother. > To be done: 1) added mbedtls_pk_write_key_pkcs8_der() write > non-encrypted pkcs8 der key 2) added mbedtls_pk_write_key_pkcs8_pem() > write non-encrypted pkcs8 pem key 3) added > mbedtls_pk_write_key_encrypted_pem() write legacy encryped pem file > with DEK-Info header 4) added > mbedtls_pk_write_key_pkcs8_encrypted_der() write to encrypted pkcs8 > der key; pkcs5 pbes1, pkcs12 and pbes2 schemes are supported 5) added > mbedtls_pk_write_key_pkcs8_encrypted_pem() same as above but pem key > 6) changed mbedtls_pem_read_buffer() which reads legacy encrypted pem > formats (with DEK-Info header) now it uses mbedtls_cipher_… functions > which allow to use any supported cipher rather than four enforced (was > limited to des-cbc, des-ede3-cbc, ars-128-cbc and aes-256-cbc) 7) > changed pk_parse_key_pkcs8_encrypted_der() 7.1) added pkcs5 pbes1 > support MD5-DES-CB CpbeWithMD5AndDES-CBC) and SHA1-DES-CBC > (pbeWithSHA1AndDES-CBC) 7.2) changed pkcs12 pbe (use same cipher for > all SHA1-DES2-EDE-CBC (pbeWithSHAAnd2-KeyTripleDES-CBC), > SHA1-DES3-EDE-CBC (pbeWithSHAAnd3-KeyTripleDES-CBC) and SHA1-RC4-128 > (pbeWithSHA1And128BitRC4); (the special > mbedtls_pkcs12_pbe_sha1_rc4_128() is not used now and may be removed) > 7.3) changed pkcs5 pbes2 support: added AES-128-CBC and AES-256-CBC > ciphers Some «preview» is available at fork > https://github.com/loafer-mka/mbedtls > <https://github.com/loafer-mka/mbedtls>, branch ‘dev_clean’ Of course, > many changes relate to obsolete formats, and may be undesirable … also > I do not touch PSK at all. > Please, give me some feedback — try to finish this with tests, pull > request, etc or not. ----------- Regards, Andrey >

5 years, 1 month

1
0
0 0

Re: [mbed-tls] mbedtls_ssl_set_bio hangs

by Ron Eggler

Just finishing off this thread: The issue appeared due to an invalid pointer access else where in the application that coincided with the mbedtls_ssl_set_bio function. Working on resolution now. Thanks for all the help, pointers & hints from the list! On 2021-06-08 2:27 p.m., Ron Eggler via mbed-tls wrote: > > Yes, there's some kind of "memory magic" going on here: > > The task got terminated due to "Load from invalid memory" > > and I see: > > |Instruction at 0x6310604d is trying to load data at 0x4, which is an > invalid memory area. You are probably dereferencing a NULL pointer.| > > |and i got some trace back addresses that point to:| > > * > > mbedtls_aes_crypt_ecb > > * > > mbedtls_ctr_drbg_random_with_add > > * > > mbedtls_ssl_handshake_step > > * > > mbedtls_ssl_handshake > > > || > > On 2021-06-08 11:43 a.m., Gilles Peskine via mbed-tls wrote: >> Hi Ron, >> >> This behavior can't be explained by the library code and the code you >> posted alone. There has to be something wrong elsewhere. >> >> Check that you aren't exceeding a limitation such as the stack size or >> the size of executable and data sections. If it can be an issue on your >> platform, check that load addresses are correct and sections don't >> overlap. Make sure there's no overlap with any device memory mapping either. >> >> Make sure that the whole binary is compiled with consistent settings. >> The layout of mbedtls_ssl_context can be influenced by the Mbed TLS >> configuration, so make sure that there's a single copy of >> mbedtls/config.h and both Mbed TLS itself and your application were >> built against that copy. The layout of mbedtls_ssl_context can also be >> influenced by compiler settings on some platforms (e.g. structure >> packing options), so make sure those are consistent across your build. >> >> That's all I can think of for now. It may help to add a lot of printf >> debugging with %p on various addresses, and compare these addresses with >> what you know about memory mappings on that platform. Good luck! >> >

5 years, 1 month

1
0
0 0

export keys in pkcs8. plain or encrypted

by Андрей Макаров

Recently I used mbedtls library in my working project. In accordance with the needs of the project, I added some functions to mbedtls for saving and loading keys in plain and encrypted pem and der forms. The changes are still raw and should be brought up to pull request requirements - there are no tests, since the functions tested as part of a working project which uses mbedtls. I can, over time, finalize the changes to a pull request, but it will take some time and effort that you don't want to waste unnecessarily — this will have to be done at my home time. If there is an interest for this work, then I will try to do it, but if few people need it or do not coincide with the general direction of development of the project, then I would not bother. To be done: 1) added mbedtls_pk_write_key_pkcs8_der() write non-encrypted pkcs8 der key 2) added mbedtls_pk_write_key_pkcs8_pem() write non-encrypted pkcs8 pem key 3) added mbedtls_pk_write_key_encrypted_pem() write legacy encryped pem file with DEK-Info header 4) added mbedtls_pk_write_key_pkcs8_encrypted_der() write to encrypted pkcs8 der key; pkcs5 pbes1, pkcs12 and pbes2 schemes are supported 5) added mbedtls_pk_write_key_pkcs8_encrypted_pem() same as above but pem key 6) changed mbedtls_pem_read_buffer() which reads legacy encrypted pem formats (with DEK-Info header) now it uses mbedtls_cipher_… functions which allow to use any supported cipher rather than four enforced (was limited to des-cbc, des-ede3-cbc, ars-128-cbc and aes-256-cbc) 7) changed pk_parse_key_pkcs8_encrypted_der() 7.1) added pkcs5 pbes1 support MD5-DES-CB CpbeWithMD5AndDES-CBC) and SHA1-DES-CBC (pbeWithSHA1AndDES-CBC) 7.2) changed pkcs12 pbe (use same cipher for all SHA1-DES2-EDE-CBC (pbeWithSHAAnd2-KeyTripleDES-CBC), SHA1-DES3-EDE-CBC (pbeWithSHAAnd3-KeyTripleDES-CBC) and SHA1-RC4-128 (pbeWithSHA1And128BitRC4); (the special mbedtls_pkcs12_pbe_sha1_rc4_128() is not used now and may be removed) 7.3) changed pkcs5 pbes2 support: added AES-128-CBC and AES-256-CBC ciphers Some «preview» is available at fork https://github.com/loafer-mka/mbedtls, branch ‘dev_clean’ Of course, many changes relate to obsolete formats, and may be undesirable … also I do not touch PSK at all. Please, give me some feedback — try to finish this with tests, pull request, etc or not. ----------- Regards, Andrey

5 years, 1 month

1
0
0 0

session resumption and renegotiation queries

by hardik dave

Dear All, I am having multiple queries regarding session resumption and renegotiation. I understand that normally session resumption is used at every new connection and session renegotiation is used on live connection. Our domain standards recommends to use session resumption to change session key ( or keyblock key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random); ) at regular intervals without closing connection and session renegotiation to change master key at regular interval using session renegotiation. This is due to the fact that the connection will be long lasting. Query 1: I understand that mbedtls currently does not support session resumption on live connection. Is there any plan to include it in the near future? ( may be similar to openssl SSL_renegotiate_abbreviated api) Query 3: If the application wants to know if session renegotiation has happened as part of mbedtls_tls_read and mbedtls_tls_write, is there any callback/API for that? --> I am only thinking of using session->start comparison in application to know if session is renegotiated. Is there any better method? Query 4: Our requirement is to understand and log security event in case failure due to certificate verification fail (revoked/expired etc..) currently we use mbedtls_ssl_get_verify_result api for same There is a case when certificate becomes expired/revoked while doing session renegotiation, mbedtls_ssl_get_verify_result api returns value 0 in above case I am thinking in case of session renegotiation, a valid session will always be available (it will not be NULL in the method below) and session renegotiation failure information will be available with session_negotiate pointer instead of session pointer in the below function. uint32_t mbedtls_ssl_get_verify_result( const mbedtls_ssl_context *ssl ) { if( ssl->session != NULL ) return( ssl->session->verify_result ); if( ssl->session_negotiate != NULL ) return( ssl->session_negotiate->verify_result ); return( 0xFFFFFFFF ); } Am I using the right API to get certificate verify_result? should mbedtls_ssl_get_verify_result api checks give priority to session_negotiate then session? I think when there is a failure, the result will always be with session_negotiate, when success session_negotiate becomes NULL and session_negotiate pointers will be assigned to session pointers. uint32_t mbedtls_ssl_get_verify_result( const mbedtls_ssl_context *ssl ) { if( ssl->session_negotiate != NULL ) return( ssl->session_negotiate->verify_result ); if( ssl->session != NULL ) return( ssl->session->verify_result ); return( 0xFFFFFFFF ); } Kind request to guide me Thanks in advance Regards Hardik Dave

5 years, 1 month

1
0
0 0

Re: [mbed-tls] mbedtls_ssl_set_bio hangs

by Ron Eggler

Yes, there's some kind of "memory magic" going on here: The task got terminated due to "Load from invalid memory" and I see: |Instruction at 0x6310604d is trying to load data at 0x4, which is an invalid memory area. You are probably dereferencing a NULL pointer.| |and i got some trace back addresses that point to:| * mbedtls_aes_crypt_ecb * mbedtls_ctr_drbg_random_with_add * mbedtls_ssl_handshake_step * mbedtls_ssl_handshake || On 2021-06-08 11:43 a.m., Gilles Peskine via mbed-tls wrote: > Hi Ron, > > This behavior can't be explained by the library code and the code you > posted alone. There has to be something wrong elsewhere. > > Check that you aren't exceeding a limitation such as the stack size or > the size of executable and data sections. If it can be an issue on your > platform, check that load addresses are correct and sections don't > overlap. Make sure there's no overlap with any device memory mapping either. > > Make sure that the whole binary is compiled with consistent settings. > The layout of mbedtls_ssl_context can be influenced by the Mbed TLS > configuration, so make sure that there's a single copy of > mbedtls/config.h and both Mbed TLS itself and your application were > built against that copy. The layout of mbedtls_ssl_context can also be > influenced by compiler settings on some platforms (e.g. structure > packing options), so make sure those are consistent across your build. > > That's all I can think of for now. It may help to add a lot of printf > debugging with %p on various addresses, and compare these addresses with > what you know about memory mappings on that platform. Good luck! >

5 years, 1 month

1
0
0 0

Re: [mbed-tls] mbedtls_ssl_set_bio hangs

by Gilles Peskine

Hi Ron, This behavior can't be explained by the library code and the code you posted alone. There has to be something wrong elsewhere. Check that you aren't exceeding a limitation such as the stack size or the size of executable and data sections. If it can be an issue on your platform, check that load addresses are correct and sections don't overlap. Make sure there's no overlap with any device memory mapping either. Make sure that the whole binary is compiled with consistent settings. The layout of mbedtls_ssl_context can be influenced by the Mbed TLS configuration, so make sure that there's a single copy of mbedtls/config.h and both Mbed TLS itself and your application were built against that copy. The layout of mbedtls_ssl_context can also be influenced by compiler settings on some platforms (e.g. structure packing options), so make sure those are consistent across your build. That's all I can think of for now. It may help to add a lot of printf debugging with %p on various addresses, and compare these addresses with what you know about memory mappings on that platform. Good luck! -- Gilles Peskine Mbed TLS developer On 08/06/2021 19:16, Ron Eggler via mbed-tls wrote: > > On 2021-06-08 7:40 a.m., Ron Eggler via mbed-tls wrote: >> On 2021-06-08 12:28 a.m., Gilles Peskine via mbed-tls wrote: >>> Hi Ron, >>> >>> The code you've shown so far only consists of setup functions that >>> populate fields in the configuration structure, then in the context >>> structure. Communication has not started yet. mbedtls_ssl_set_bio in >>> particular is a very simple setter function. >>> >>> Where does the code actually hang? Have some messages already been >>> exchanged on the network at that point? Can you get a stack trace? >>> >>> Best regards, >>> >> Hi Gilles, >> >> Thank you for the response! >> >> I've inserted print statements after each of the setup functions and >> can see that it never gets past mbedtls_ssl_set_bio. The messages >> that have been exchanged, include the complete bring up and login of >> the control channel, on the data channel, I call >> mbedtls_x509_crt_init >> mbedtls_pk_init >> mbedtls_entropy_init >> mbedtls_ctr_drbg_init >> mbedtls_ssl_init >> mbedtls_ssl_config_init >> followed by the certificate and key file got parsing, seeding of the >> RNG and that's where the previously mentioned procedure with >> mbedtls_ssl_config_defaults() starts. >> I unfortunately do not have a debugger available on that platform and >> hence getting a stack trace won't be so straight forward. Do you have >> any pointers as to what could be the issue potentially? >> >> Thank you, >> >> Ron > > Okay, I've made some further findings: > > I changed the mbedtls_ssl_set_bio funmction so that I inserted a print > statement on entry and after every set line, like so: > > void mbedtls_ssl_set_bio( mbedtls_ssl_context *ssl, > void *p_bio, > mbedtls_ssl_send_t *f_send, > mbedtls_ssl_recv_t *f_recv, > mbedtls_ssl_recv_timeout_t *f_recv_timeout ) > { > iprintf("mbedtls_ssl_set_bio::entry\n"); > ssl->p_bio = p_bio; > iprintf("mbedtls_ssl_set_bio::p_bio set\n"); > ssl->f_send = f_send; > iprintf("mbedtls_ssl_set_bio::f_send set\n"); > ssl->f_recv = f_recv; > iprintf("mbedtls_ssl_set_bio::f_recv set\n"); > ssl->f_recv_timeout = f_recv_timeout; > iprintf("mbedtls_ssl_set_bio::f_recv_timeout set\n"); > } > > and turns out, that I only see the very first print on > "mbedtls_ssl_set_bio::entry\n" and nothing there after, which leads me > to the believe that my *ssl is invalid which is odd as that variable > is also used for ret = mbedtls_ssl_setup( &ssl_d, &conf_d ); and it is > initialized at the beginning of the function with mbedtls_ssl_init( > &ssl_d ); > >

5 years, 1 month

1
0
0 0

Re: [mbed-tls] mbedtls_ssl_set_bio hangs

by Ron Eggler

On 2021-06-08 7:40 a.m., Ron Eggler via mbed-tls wrote: > On 2021-06-08 12:28 a.m., Gilles Peskine via mbed-tls wrote: >> Hi Ron, >> >> The code you've shown so far only consists of setup functions that >> populate fields in the configuration structure, then in the context >> structure. Communication has not started yet. mbedtls_ssl_set_bio in >> particular is a very simple setter function. >> >> Where does the code actually hang? Have some messages already been >> exchanged on the network at that point? Can you get a stack trace? >> >> Best regards, >> > Hi Gilles, > > Thank you for the response! > > I've inserted print statements after each of the setup functions and > can see that it never gets past mbedtls_ssl_set_bio. The messages that > have been exchanged, include the complete bring up and login of the > control channel, on the data channel, I call > mbedtls_x509_crt_init > mbedtls_pk_init > mbedtls_entropy_init > mbedtls_ctr_drbg_init > mbedtls_ssl_init > mbedtls_ssl_config_init > followed by the certificate and key file got parsing, seeding of the > RNG and that's where the previously mentioned procedure with > mbedtls_ssl_config_defaults() starts. > I unfortunately do not have a debugger available on that platform and > hence getting a stack trace won't be so straight forward. Do you have > any pointers as to what could be the issue potentially? > > Thank you, > > Ron Okay, I've made some further findings: I changed the mbedtls_ssl_set_bio funmction so that I inserted a print statement on entry and after every set line, like so: void mbedtls_ssl_set_bio( mbedtls_ssl_context *ssl, void *p_bio, mbedtls_ssl_send_t *f_send, mbedtls_ssl_recv_t *f_recv, mbedtls_ssl_recv_timeout_t *f_recv_timeout ) { iprintf("mbedtls_ssl_set_bio::entry\n"); ssl->p_bio = p_bio; iprintf("mbedtls_ssl_set_bio::p_bio set\n"); ssl->f_send = f_send; iprintf("mbedtls_ssl_set_bio::f_send set\n"); ssl->f_recv = f_recv; iprintf("mbedtls_ssl_set_bio::f_recv set\n"); ssl->f_recv_timeout = f_recv_timeout; iprintf("mbedtls_ssl_set_bio::f_recv_timeout set\n"); } and turns out, that I only see the very first print on "mbedtls_ssl_set_bio::entry\n" and nothing there after, which leads me to the believe that my *ssl is invalid which is odd as that variable is also used for ret = mbedtls_ssl_setup( &ssl_d, &conf_d ); and it is initialized at the beginning of the function with mbedtls_ssl_init( &ssl_d );

5 years, 1 month

1
0
0 0

Re: [mbed-tls] mbedtls_ssl_set_bio hangs

by Ron Eggler

On 2021-06-08 12:28 a.m., Gilles Peskine via mbed-tls wrote: > Hi Ron, > > The code you've shown so far only consists of setup functions that > populate fields in the configuration structure, then in the context > structure. Communication has not started yet. mbedtls_ssl_set_bio in > particular is a very simple setter function. > > Where does the code actually hang? Have some messages already been > exchanged on the network at that point? Can you get a stack trace? > > Best regards, > Hi Gilles, Thank you for the response! I've inserted print statements after each of the setup functions and can see that it never gets past mbedtls_ssl_set_bio. The messages that have been exchanged, include the complete bring up and login of the control channel, on the data channel, I call mbedtls_x509_crt_init mbedtls_pk_init mbedtls_entropy_init mbedtls_ctr_drbg_init mbedtls_ssl_init mbedtls_ssl_config_init followed by the certificate and key file got parsing, seeding of the RNG and that's where the previously mentioned procedure with mbedtls_ssl_config_defaults() starts. I unfortunately do not have a debugger available on that platform and hence getting a stack trace won't be so straight forward. Do you have any pointers as to what could be the issue potentially? Thank you, Ron

5 years, 1 month

1
0
0 0

FW: How to map PSA method to openssl method

by Gyorgy Szing

Hi, Can you please help Jun to find an answer to is question? (See below.) /George ---------- Forwarded message --------- 发件人： Jun Nie <jun.nie(a)linaro.org> Date: 2021年6月7日周一下午2:31 Subject: How to map PSA method to openssl method To: <mbed-tls(a)lists.trustedfirmware.org> Hi, I want to sign a data on PC with openssl, and verifiy it with PSA-RoT on board. Does anybody know how to map PSA method to openssl method? Such as: psa_sign_hash(key_handle, PSA_ALG_DETERMINISTIC_ECDSA(PSA_ALG_SHA_256), hash, hash_len, sig, sizeof(sig), sig_len); Regards, Jun

5 years, 1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls