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