Hi Ilias,
On 10/27/26 13:01, Ilias Apalodimas wrote:
Apologies for the late reply.
Was waiting for some announcements to settle down.
What I found out was this [0]. Comments welcome but I'd like to see
how this plays out before making any decisions, since we use mbedTLS
for https as well
[0]
https://lists.trustedfirmware.org/archives/list/[email protected]/thread/YPIGCB7WN6GCHOGEGKOJXUYAP7OK527W/
Thanks
/Ilias
Thanks for checking. Should I address Simon’s comments and send a v2 of
the Linux based ML-DSA series or hold off until the direction for crypto
integration in U-Boot is clearer?
On Thu, 24 Sept 2026 at 13:36, Ilias Apalodimas
<[email protected]> wrote:
[...]
Well, a problem I see is that this is something that needs active
maintenance to stay in sync as we don't want to miss important fixes
here. In theory, we get that with mbedtls (even if we're behind atm...).
Agreed. Importing the Linux implementation means taking responsibility
for tracking upstream fixes. I’m willing to maintain this code, track
changes to the Linux implementations and bring relevant fixes into
U-Boot. I can also add a MAINTAINERS entry to make that responsibility
explicit.
The goal is to prepare U-Boot for early adoption of post-quantum
cryptography in secure boot, particularly FIT image signing and
signature verification as some hardware already ships with PQC
capabilities.
There are zero doubts that this is necessary; in fact we are already late.
The intention is to switch to Mbed TLS as soon as it provides production
ready ML-DSA support and the required SHAKE functionality. That timeline
is not clear to me yet so I’d like to prepare U-Boot in the meantime.
Would this address your maintenance concern sufficiently to proceed with
this approach?
I can try to find out more about the mbedTLS roadmap if you are still
interested in going down that path. Arguably most country legislation
is looking to enforce PQC by 2030 so a month or two won't kill us.
There's another benefit apart from the 'less maintenance' when using
the external library path. IIRC, there isn't a single algorithm
acceptable to all legislative bodies.E.g, CNSA 2.0 does not adopt
SLH-DSA while most of Europe does. It would be much easier to use a
library and select the desired implementation (even stateful vs
stateless) instead of importing and maintaining everything.
Thanks, any clarification you can get on the mbedTLS roadmap and the
expected timeline for production-ready PQC support would be helpful.
Will do
Separately from that U-Boot currently uses mbedTLS 3.6.x and moving to
newer 4.x involves the split into TF-PSA-Crypto as a separate submodule
and incompatible API changes. That migration is work to consider
independently of PQC support.
Yes last time I looked the gap wasn't massive, but it's there and
indeed frustrating.
Let’s revisit the PQC approach once we have more information on the roadmap.
Will do get back to you!
Thanks
/Ilias
Mit freundlichen Grüßen / Kind regards
--
Ayoub Zaki
Embedded Systems Consultant
Vaihinger Straße 2/1
D-71634 Ludwigsburg
Email : [email protected]
Homepage : https://embetrix.com
