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