- mbed-tls - lists.trustedfirmware.org

TLS Handshake failure while connecting to mqtt broker from device

by urvi＠milltech.in

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

2 years, 9 months

1
0
0 0

Setup to test and debug a single funciton.

by Victor Micó

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

2 years, 9 months

1
0
0 0

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

by heinrich.mueller＠g-ushin.com

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

2 years, 10 months

2
1
0 0

How to secure two simultaneous sockets?

by Fred Wedemeier

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

2 years, 10 months

1
0
0 0

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

by arman_ilmak＠yahoo.com

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

2 years, 10 months

1
0
0 0

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

by heinrich.mueller＠g-ushin.com

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

2 years, 10 months

2
2
0 0

*_ALT vs PSA for HW crypto and upstreaming

by mathieu.rondonneau＠broadcom.com

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

2 years, 10 months

3
2
0 0

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

by Peter

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

2 years, 10 months

1
0
0 0

Reminder: MBed TLS Technical Forum next Monday

by don.harbin＠linaro.org

Hi All, This is a gentle reminder that the next MBed TLS Tech forum is next Monday 4:30 PM UK time. If you have any topics, please let Dave Rodgman know. :) Best regards, Don MBed TLS Technical Forum Monday Jul 4, 2022 ⋅ 8:30am – 9:30am Mountain Standard Time - Phoenix Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum Time: Oct 25, 2021 04:30 PM London Every 4 weeks on Mon, 20 occurrence(s) Oct 25, 2021 04:30 PM Nov 22, 2021 04:30 PM Dec 20, 2021 04:30 PM Jan 17, 2022 04:30 PM Feb 14, 2022 04:30 PM Mar 14, 2022 04:30 PM Apr 11, 2022 04:30 PM May 9, 2022 04:30 PM Jun 6, 2022 04:30 PM Jul 4, 2022 04:30 PM Aug 1, 2022 04:30 PM Aug 29, 2022 04:30 PM Sep 26, 2022 04:30 PM Oct 24, 2022 04:30 PM Nov 21, 2022 04:30 PM Dec 19, 2022 04:30 PM Jan 16, 2023 04:30 PM Feb 13, 2023 04:30 PM Mar 13, 2023 04:30 PM Apr 10, 2023 04:30 PM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJEkceuurT4sGdaksikbUn6FARB9Kuk3ac2o/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/95962635632?pwd=STFkQVltejAzRDJ6NmoxZjhmZC9RUT… Meeting ID: 959 6263 5632 Passcode: 018366 One tap mobile +13462487799,,95962635632# US (Houston) +16699009128,,95962635632# US (San Jose) Dial by your location +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) +1 301 715 8592 US (Washington DC) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 959 6263 5632 Find your local number: https://linaro-org.zoom.us/u/aewUpnQu5y Guests psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org nnac123(a)gmail.com

2 years, 10 months

1
0
0 0

Is tls.mbed.org down?

by Max Peng

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

2 years, 10 months

3
4
1 0

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

by Manuel Pegourie-Gonnard

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

2 years, 10 months

1
0
0 0

Verify cert chain

by Subramanian Gopi Krishnan

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

2 years, 10 months

1
0
0 0

VIA padlock support

by Gilles Peskine

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

2 years, 10 months

1
0
0 0

Clear master secret from mbedtls_ssl_session after handshake is ready

by Maarten Meijer

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

2 years, 10 months

2
3
0 0

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

by don.harbin＠linaro.org

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

2 years, 11 months

1
0
0 0

Reminder: MBed TLS Technical Forum June 6th

by Don Harbin

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

2 years, 11 months

1
0
0 0

PSA API on non-threaded environment

by gergely.nagymate＠generalmechatronics.com

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

2 years, 11 months

2
1
0 0

PSA API on non-threaded environment

by Gergely Nagymáté

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

2 years, 11 months

1
0
0 0

"RAW RSA" encoding method for signatures

by THIERRY BINIGUER

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

2 years, 11 months

2
1
0 0

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

by Mike Holmes

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

2 years, 11 months

1
0
0 0

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

by santosdanillo＠gmail.com

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

2 years, 11 months

1
0
0 0

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

by santosdanillo＠gmail.com

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

2 years, 11 months

1
0
0 0

Require cross compilation steps

by Krunal Chauhan

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

2 years, 11 months

1
0
0 0

Re: AES Memory Leak

by Minos Galanakis

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

3 years

1
0
0 0

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

by Christie Su

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

3 years

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls