Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday at 4:30pm UK time. Invite details can be found on the online
calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Janos know. :)
Don
My mbedtls client has been working for 2 years. It did what I required and
has been stable.
However, I now need to force a new server to use my preferred cipher suite.
I found the helper function to force the cipher suite here:
https://github.com/Mbed-TLS/mbedtls/blob/de4d5b78558666d2e258d95e6c5875f9c7…
I added mbedtls_ssl_conf_preference_order(conf,
MBEDTLS_SSL_SRV_CIPHERSUITE_ORDER_CLIENT) to the end of the function to
force the server to choose my ciphersuite.
Prior to this change I called the mbedtls functions in this chronological
order:
mbedtls_ssl_init(&_ssl);
mbedtls_ssl_config_init(&_conf);
mbedtls_ctr_drbg_init(&_ctr_drbg);
mbedtls_entropy_init(&_entropy);
mbedtls_x509_crt_init(&_cacert);
mbedtls_pk_init(&_pkey);
mbedtls_ctr_drbg_seed
mbedtls_ssl_config_defaults
mbedtls_ssl_conf_rng
mbedtls_ssl_conf_authmode
mbedtls_x509_crt_parse_file
mbedtls_ssl_conf_ca_chain
mbedtls_ssl_setup
mbedtls_ssl_set_hostname
and then proceed to call:
mbedtls_ssl_set_bio
mbedtls_ssl_handshake
Now:
If I call mbedtls_ssl_conf_ciphersuites BEFORE mbedtls_ssl_config_defaults,
the ciphersuite list is ignored/seems to get overriden.
If I call mbedtls_ssl_conf_ciphersuites AFTER mbedtls_ssl_config_defaults,
my ciphersuite list changes are accepted and transmitted (I can see in
Wireshark). The server then responds agreeing to use my chosen cipher suite.
However, mbedtls_ssl_handshake returns with value -26112, which I have
looked up to be MBEDTLS_ERR_SSL_ILLEGAL_PARAMETER.
Unfortunately I have no clue what is causing this.
Could somebody please advise how this should be done? I can see Client2
example but there are functions I have which are not in there. Client1
seems too simple for me but Client2 seems beyond what I require.
I am using MbedTLS client code based on this:
https://github.com/machinezone/IXWebSocket/blob/master/ixwebsocket/IXSocket…
I am connecting to a server via it's URL. However, I would like to connect directly using an IP address returned from running the traceroute command on the URL.
So I replaced the URL with the IP address. However, MBedTLS fails on the handshake:
https://github.com/machinezone/IXWebSocket/blob/master/ixwebsocket/IXSocket…
I get the error:
"error in handshake : X509 - Certificate verification failed, e.g. CRL, CA or signature check failed"
If I revert back to URL, it works. The IP address does exist.
How can I connect using the IP address, instead of the URL?
Micron Confidential
Hi,
I find that mbed-tls already support LMS, could you please Point to some reference and starting from which version mbedTLS lib version supports LMS?
Best Regards,
Raunak
Get Outlook for iOS<https://aka.ms/o0ukef>
Micron Confidential
Micron Confidential
Dear MbedTLS,
Can you please help to provide some references for LMS stateful signatures schemes support in MbedTLS,
May be something like documentation and github repo link?
Unfortunately I am not able to find it online?
Thanks,
Raunak
Get Outlook for iOS<https://aka.ms/o0ukef>
Micron Confidential
________________________________
From: Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com>
Sent: Tuesday, September 3, 2024 8:48 PM
To: Raunak Gupta <raunakgupta(a)micron.com>; enquiries(a)trustedfirmware.org <enquiries(a)trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: [EXT] RE: Inquiry About PQC Cryptos in embedTLS Library
Micron Confidential
CAUTION: EXTERNAL EMAIL. Do not click links or open attachments unless you recognize the sender and were expecting this message.
Hi Raunak,
Mbed TLS today supports LMS stateful hash-based signature scheme. While supporting other PQC algorithms is in the Mbed TLS project roadmap, the team isn’t actively working on it. The focus for the team now is preparing for Mbed TLS 4.0.
Feel free to ask any further technical questions in the Mbed TLS public mailing list - mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> (https://lists.trustedfirmware.org/mailman3/lists/mbed-tls.lists.trustedfirm…)
Regards,
Shebu
Micron Confidential
From: 'Raunak Gupta' via TFenquiries <enquiries(a)trustedfirmware.org>
Sent: Tuesday, September 3, 2024 2:34 AM
To: enquiries(a)trustedfirmware.org
Subject: Inquiry About PQC Cryptos in embedTLS Library
Micron Confidential
Dear Trusted Firmware Team,
I hope this message finds you well. My name is Raunak, and I am a Security Engineer at Micron Technology.
I would like to inquire whether the embedTLS library has been updated to include Post-Quantum Cryptography (PQC) algorithms such as LMS, HSS, and XMSS.
Additionally, is the embedTLS team actively working on integrating these PQC algorithms?
Thank you for your assistance.
Best regards,
Raunak
Micron Confidential
To unsubscribe from this group and stop receiving emails from it, send an email to enquiries+unsubscribe(a)trustedfirmware.org<mailto:enquiries+unsubscribe@trustedfirmware.org>.
Dear Mbed TLS users,
We have released Mbed TLS versions 3.6.1 and 2.28.9. These releases provide bugfixes, security fixes and minor improvements.
The 3.6.1 release includes fixes for issues caused by enabling TLS 1.3 for TLS connections in the default configuration.
Full details are available in the release notes:
https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-2.28.9https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.1
We recommend all users to consider whether they are impacted, and to upgrade appropriately.
Many thanks,
David Horstmann
Mbed TLS developer
Hi all,
From the announcement and also the long term plans (https://mbed-tls.readthedocs.io/en/latest/project/long-term-plans/) it is apparent that bignum/ecp operations on the public API will go away and usage will be restricted to internal only.
I do understand and welcome the shift towards PSA API and to abandon the ALT interface for higher level legacy API crypto functions. However, I'm not so positive about removal of the bignum and ecp API. There are projects using those functions even in their PSA porting layer (Matter comes to mind: https://github.com/project-chip/connectedhomeip/blob/master/src/crypto/CHIP…) or projects using the bignum layer as abstraction (Zephyr hostap/wpa_supplicant: https://github.com/zephyrproject-rtos/hostap/tree/main/src/crypto, crypto_mbedtls*.c).
There might be a case to support those functions to have (hardware-accelerated) low level building blocks for algorithms Mbed TLS doesn't yet or never will support. As other SSL libraries such as OpenSSL also expose similar API (BN_ and EC_POINT_ ), the removal in Mbed TLS will certainly leave a gap.
What's the view here from the project team?
Cheers,
Gernot
Hi,
We are in the process of qualifying a suitable encryption library for our pre-hospital patient monitor and the telemedicine system. I am writing to request your guidance regarding the mbed-tls use for commercial purposes. I look forward to your response.
Regards,
Praveen Kumar
R&D Project Manager
Emergency Care Professional (EC-Pro)
Philips
Tel +44 (0) 1256 362427 Email praveen.m.kumar(a)philips.com<mailto:praveen.m.kumar@philips.com>
Remote Diagnostic Technologies Limited. Registered office: Ascent 1, Farnborough Aerospace Centre, Aerospace Boulevard, Farnborough GU14 6XW, UK. Registered in England No. 3321782.
[Logo Description automatically generated]<http://www.philips.com/>
Connect with Philips
[cid:image002.gif@01DAE7F8.0802FC50]<https://www.linkedin.com/company/philips/>[cid:image003.gif@01DAE7F8.0802FC50]<https://twitter.com/PhilipsHealth>[cid:image004.gif@01DAE7F8.0802FC50]<https://www.youtube.com/PhilipsHealthcare/videos>
________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
Hello,
Following consultations with the community and internal discussions
among the Mbed TLS maintenance team, we can now present the major
changes that will happen in the next major version of Mbed TLS. Our plan
remains to release in the second quarter of 2025.
The next major version will focus on two things:
1. The cryptography library will be a separate product called
TF-PSA-Crypto 1.0. The X.509 and TLS library will be called Mbed TLS
4.0, and will rely on TF-PSA-Crypto for all cryptographic functionality.
2. This release completes the migration of cryptography APIs from
classic mbedtls APIs to PSA APIs.
Please find more information below about what this means in practice.
What follows are just headlines, not an exhaustive list of changes. We
expect many small changes that do not affect major functionality.
Please note that the changes presented here are our current plan. We may
revise it based on new inputs, new insights or unexpected hurdles. You
can follow the advancement of the design, planning and development of
the next release on the 4.0+1.0 planning board at
https://github.com/orgs/Mbed-TLS/projects/15/views/1 .
Removal of legacy APIs
The following low-level application interfaces will no longer be present
in the API of TF-PSA-Crypto 1.0 and Mbed TLS 4.0:
* Hashes: hkdf.h, md5.h, ripemd160.h, sha1.h, sha3.h, sha256.h, sha512.h;
* Random generation: ctr_drbg.h, hmac_drbg.h, entropy.h;
* Ciphers and modes: aes.h, aria.h, camellia.h, chacha20.h,
chachapoly.h, cipher.h, cmac.h, gcm.h, poly1305.h;
* Private key encryption mechanisms: pkcs5.h, pkcs12.h.
* Asymmetric cryptography: bignum.h, dhm.h, ecdh.h, ecdsa.h,
ecjpake.h, ecp.h, rsa.h.
The cryptographic mechanisms remain present, but they will only be
accessible via the PSA API (psa_xxx functions introduced gradually
starting with Mbed TLS 2.17).
If you maintain code that uses these interfaces, you can already start
migrating it today, since almost all PSA interfaces are available in the
mbedtls-3.6 long-time support branch (and many even in 2.28 LTS). Please
consult the PSA transition guide
https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-3.6/docs/psa-transition.md
for guidance.
Some non-PSA crypto interfaces will still be present in TF-PSA-Crypto 1.0:
* pk.h will remain with some changes, mainly to provide an interface
to key parsing and formatting which does not have a PSA equivalent yet.
* md.h will remain as a thin layer over PSA hash functions (not HMAC)
to ease the transition.
* nist_kw.h will remain because it does not have a PSA equivalent yet.
Removal of legacy integration interfaces
TF-PSA-Crypto 1.0 and Mbed TLS 4.0 will no longer support
MBEDTLS_xxx_ALT replacement of functions and modules. Use PSA
transparent drivers instead.
TF-PSA-Crypto 1.0 and Mbed TLS 4.0 will no longer support
MBEDTLS_PK_RSA_ALT and MBEDTLS_PSA_CRYPTO_SE_C. Use PSA opaque drivers
instead.
TF-PSA-Crypto 1.0 and Mbed TLS 4.0 will no longer have the
mbedtls/entropy.h interface to configure entropy sources. This will be
replaced by PSA random drivers.
In addition, we are planning to rework the platform abstraction layer
(MBEDTLS_PLATFORM_xxx configuration options). More details will be
available in the coming months.
Removal of legacy mechanisms
The following cryptographic mechanisms are planned to be removed in
TF-PSA-Crypto 1.0 and Mbed TLS 4.0:
* DES (including 3DES).
* PKCS#1v1.5 encryption/decryption (RSAES-PKCS1-v1_5). (OAEP, PSS, and
PKCS#1v1.5 signature are staying.)
* Finite-field Diffie-Hellman with custom groups. (RFC 7919 groups
remain supported.)
* Elliptic curves of size 225 bits or less.
The following cipher suites are planned to be removed from (D)TLS 1.2 in
Mbed TLS 4.0:
* TLS_RSA_* (including TLS_RSA_PSK_*), i.e. cipher suites using RSA
decryption. (RSA signatures, i.e. TLS_ECDHE_RSA_*, are staying.)
* TLS_ECDH_*, i.e. cipher suites using static ECDH. (Ephemeral ECDH,
i.e. TLS_ECDHE_*, is staying.)
* TLS_DHE_*, i.e. cipher suites using finite-field Diffie-Hellman.
(Ephemeral ECDH, i.e. TLS_ECDHE_*, is staying.)
* TLS_*CBC*, i.e. all cipher suites using CBC.
Non-functional changes
Due to the separation into two separate products (TF-PSA-Crypto and Mbed
TLS), there will be major changes to the directory structure and to the
build system. We plan to use CMake as the primary build system.
Since TF-PSA-Crypto is a new product, identifiers that are not PSA
interfaces (such as optimisation options and platform interfaces) will
be renamed with a new prefix.
Best regards,
--
Gilles Peskine
Mbed TLS developer
Hi,
ECB is unsecure, see
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_cod…
and shouldn't be used in production.
So, I have switched to one of CBC/CMAC/CTR modes, but in
`mbedtls_cipher_cmac_starts`
I see that it only accepts ECB variants, and also doesn't seem to be
using the `type`.
From https://github.com/Mbed-TLS/mbedtls/issues/8617 I see that ECB
for AES was intentional,
even for the CMAC API.
Is this expected?
1. Is using ECB for CMAC API correct?
2.Shouldn't we remove the ECB altogether?
Appreciate any clarifications.
Cheers,
Chaitanya.
