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