The end of MbedTLS development?

[peter-h]

On email today:

Dear Mbed TLS Users,

We are preparing for a transition in the maintenance of TLS and X.509 libraries (both contained in
the Mbed TLS project).

The existing maintainers will continue to develop and maintain TF-PSA-Crypto, which remains an
actively maintained part of the project.

The existing maintainers will cease their involvement in their development and maintenance
of Mbed TLS from April 2027.

Unless new maintainers have joined the project and ramped up by that time, security incident
response, security fixes, and releases will cease from April 2027.

The future maintenance arrangements for the TLS and X.509 libraries have not yet been determined. We
welcome contributions from organisations and individuals interested in helping sustain Mbed TLS,
whether through engineering resources, funding, or other forms of support. The existing
maintainers are committed to supporting new maintainers as they ramp up and take on responsibility
for the libraries.

If you or your organisation are interested in contributing to the future maintenance of Mbed TLS,
please contact [email protected].

We recognise the importance of these libraries to their users and the wider ecosystem, and hope
that, with community involvement, a sustainable path forward can be established.

Kind regards,
The Mbed TLS Team

I have v2.16.2 in a project (from some 6 years ago) and it works just fine, for an https client. My impression for the last few years is that they have run out of useful stuff to do and started going sideways, with stuff like zeroing malloc'd buffers before freeing them ("nice" but if the attacker is inside your box to the required extent, you've had it anyway). Then "quantum resistant crypto" whatever that is.

I also get the feeling that users got fed up with the constant stream of new versions and API changes, each taking a lot of work to integrate and test.

[Siwastaja]

Why care? I asked Claude today for a flash diet. Already carefully tuned-down mbedTLS got largest saving of 27KB of flash and 9KB of RAM. It did replace the whole EC math with some other, properly licensed optimized ASM implementation, removed all dead paths and unused TLS features not already taken care of by the LTO, dropped TLS handshake time from 1.7 seconds to 0.1 seconds, fixed a security bug it found along the way. It installed a Cortex-M4 emulator and ran the machine code on it, plus extensive testing on PC-compiled target.

This was part of 10 other agents all working with different parts of the codebase for the same goal. After major rewrite of many core parts, the whole thing booted and connected and I haven't found a single bug in it yet.

What's most astonishing is the amount of verification and testing effort that went into it. It's a 6-month human project squeezed into 2.5 hours. It's all customized work for your own project, which means it's optimal. It also has less attack surface.

You don't have to wonder if mbedTLS is maintained or not, or if some other library is better, or whatever. You just ask what you need and get it done. Either from scratch, or modifying what you start with. Both work.

[peter-h]

OK you probably understand the detail of how it all works; I am sure most people don't.

dropped TLS handshake time from 1.7 seconds to 0.1 seconds

How was that achieved?

Yes indeed Claude is now very good. Productivity up 10x at least, 100x if the project involves learning about some totally new chip.

[Bud]

What level of subscription got you that?

[nimish]

Why care? I asked Claude today for a flash diet. Already carefully tuned-down mbedTLS got largest saving of 27KB of flash and 9KB of RAM. It did replace the whole EC math with some other, properly licensed optimized ASM implementation, removed all dead paths and unused TLS features not already taken care of by the LTO, dropped TLS handshake time from 1.7 seconds to 0.1 seconds, fixed a security bug it found along the way. It installed a Cortex-M4 emulator and ran the machine code on it, plus extensive testing on PC-compiled target.

This was part of 10 other agents all working with different parts of the codebase for the same goal. After major rewrite of many core parts, the whole thing booted and connected and I haven't found a single bug in it yet.

What's most astonishing is the amount of verification and testing effort that went into it. It's a 6-month human project squeezed into 2.5 hours. It's all customized work for your own project, which means it's optimal. It also has less attack surface.

You don't have to wonder if mbedTLS is maintained or not, or if some other library is better, or whatever. You just ask what you need and get it done. Either from scratch, or modifying what you start with. Both work.

Of all the things to hand roll, even with an AI/LLM tool, crypto is probably the least I'd choose. Curious what TLS lib is even out there since wolf is GPL.

[NorthGuy]

dropped TLS handshake time from 1.7 seconds to 0.1 seconds

Gives you an idea of how much bloat the "best programming practices" produce.

[peter-h]

I suspect the answer to 1.7 -> 0.1 is something altogether different

Probably some special case after unused code has been stripped out. MbedTLS tried to be all things to all men. It has huge potential for stripping down. It is much smaller if you control both ends and are building just say a client. But then you are not selling a product with TLS that's generally usable with various customer servers.

[SiliconWizard]

So, your concern about MbedTLS being affected by the EOL announcement for Mbed itself was in the end justified.

And so while they recognize many companies are dependent on it, they just hope that the "community" will do the job. In other words: "we don't care now, good luck."

We recognise the importance of these libraries to their users and the wider ecosystem, and hope
that, with community involvement, a sustainable path forward can be established.

[bradyok]

I suspect the answer to 1.7 -> 0.1 is something altogether different

  I think the numbers explain it without a special case. On a Cortex-M4, a client handshake spends nearly all its time in P-256: one ECDHE exchange, then verifying the server's signature and its certificate's signature. mbedTLS's own benchmark
  example puts those at roughly 570 ms for the ECDHE and 590 ms per verify on an M4. That adds up to about 1.7 s.

  Siwastaja said the EC math was swapped for an optimized assembly implementation. The best-known one is Emil Lenngren's P256-Cortex-M4 (MIT licence, constant time). It does key generation in 5.1 ms, the ECDH shared secret in 14.2 ms and a verify in
  15.3 ms, at 64 MHz. The same three steps come to about 50 ms. So 0.1 s for the whole handshake is about what you'd expect.

  https://github.com/Emill/P256-Cortex-M4

  It also mostly answers your point about servers you don't control. RSA-2048 public-key operations (the verify side) were already fast in mbedTLS, around 30 to 40 ms on an M4. Elliptic curves were the slow part.

  One trap: the p256-m driver bundled with mbedTLS 3.5 and later is not the speed answer. It was designed for small code size first. Its ECDSA verify takes 309 ms on an M4, slower than TinyCrypt.

 

Curious what TLS lib is even out there since wolf is GPL.

  First, the scope of the announcement: only the TLS and X.509 layers are losing their maintainers. The same team keeps maintaining TF-PSA-Crypto, so the primitives stay supported. Worth knowing if you're on 4.1: it was announced as an LTS supported
  "until at least March 2029", and for the TLS part that now depends on someone taking over. April 2027 is also right after 3.6 LTS ends.

  https://lists.trustedfirmware.org/archives/list/[email protected]/thread/YPIGCB7WN6GCHOGEGKOJXUYAP7OK527W/

  Options, depending on the target:

  - Embedded Linux: rustls (Apache-2.0/MIT/ISC). I've been replacing an Appweb + mbedTLS web stack in some embedded Linux controllers with Rust and rustls. It also runs on no_std since 0.23, but you have to supply an allocator and a random number
    generator.
  - Bare-metal MCU in Rust: embedded-tls (Apache-2.0). It's a TLS 1.3 client with no allocator, now maintained under embassy-rs. It's still marked work in progress.
  - BearSSL (MIT) is small and well designed, but it's TLS 1.2 only, calls itself beta, and has had no release since 2018. It has the same maintenance problem, only sooner.
  - wolfSSL moved from GPLv2 to GPLv3 in 5.8.2, and the commercial licence is still available.

  On AI and crypto: I'm a heavy Claude user, and what Siwastaja describes is the sensible version. Swapping in an existing, licensed, constant-time assembly library is not the same as having the AI invent elliptic-curve math. I'd draw the line there:
  let it strip the config, remove dead code and write the glue, but keep the primitives vetted. A wrong answer is easy to see. A timing leak isn't.

[Siwastaja]

I suspect the answer to 1.7 -> 0.1 is something altogether different

  I think the numbers explain it without a special case. On a Cortex-M4, a client handshake spends nearly all its time in P-256: one ECDHE exchange, then verifying the server's signature and its certificate's signature. mbedTLS's own benchmark
  example puts those at roughly 570 ms for the ECDHE and 590 ms per verify on an M4. That adds up to about 1.7 s.

  Siwastaja said the EC math was swapped for an optimized assembly implementation. The best-known one is Emil Lenngren's P256-Cortex-M4 (MIT licence, constant time). It does key generation in 5.1 ms, the ECDH shared secret in 14.2 ms and a verify in
  15.3 ms, at 64 MHz. The same three steps come to about 50 ms. So 0.1 s for the whole handshake is about what you'd expect.

Correct. Speedup came from this replacement.

[Siwastaja]

What level of subscription got you that?

The $20 subscription would have done that, probably with an extra 2.5 hour wait in the middle of the things for a usage limit reset. $200 subscription did that, and 9 other similar things in parallel, without hitting usage limits (but getting quite close). So I guess $100 subscription would have done 3 similar things in parallel. And $20 tier blocked once on the 5-hour usage window wait.

[peter-h]

I got the impression that MbedTLS devs collected whatever open source algorithms they could find (which is totally reasonable) and a lot of these were old. I saw this in their AES code. I measured AES256 at 800kbytes/sec. That can be substantially optimised by using more tables (same with DES actually). FWIW, the 1k TinyAES does 100kbytes/sec (168MHz 32F417).

But everything has to end. LWIP de facto ended some 10 years ago. But it works.

[tellurium]

I got the impression that MbedTLS devs collected whatever open source algorithms they could find (which is totally reasonable) and a lot of these were old.

We do the same. Writing your own crypto implementation from scratch is not the brightest idea.

[peter-h]

Presumably Claude is now able to ingest the whole of MbedTLS and spit out a version with all patches and updates fixed but using the existing API so you don't have to re-hash your product.

Obviously that won't give you a due diligence backstop though. One of the unhappy people on the MbedTLS mailing list signed his very public email with his company name: Schneider Automation

[NorthGuy]

Presumably Claude is now able to ingest the whole of MbedTLS and spit out a version with all patches and updates fixed but using the existing API so you don't have to re-hash your product.

Also, it can re-write your code, so you don't need to worry about the API being the same.