MbedTLS - which cipher suites are advisable to support, and memory usage reduction

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

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.


Has anyone any comments on the above?


how you can see the Mbed TLS category of Mbed support forum is not very active, and also take a to look at this topic .

BR, Jan

Hello Jan,

I think I posted it there (have lost the link) but IIRC there was no
response either.

The feeling I get is that this code needs a lot of fixes to make it
work for people, but most of those who fix stuff don’t contribute the
fixes. I’ve had some comms with some disillusioned potential users who
have gone to some other commercially supported TLS library.

I’ve been working on a STM 32F417 project using Cube IDE and all that
stuff is unsupported, with people posting “desperate” questions on
various forums :slight_smile:

The immediate issues with MbedTLS are a) the general memory usage,
which looks like nearly 50k per TLS session, and b) the inability to
process (stream) the ~200k block of root certificates without needing
200k of RAM.

Kind regards,