Hi Ilias,
On 9/24/26 08:00, Ilias Apalodimas wrote:
Hi all,
First of all, Ayoub thanks for doing this. It's on my backlog for a
number of years :)
On Wed, 23 Sept 2026 at 22:58, Ayoub Zaki <[email protected]> wrote:
Hi Tom,
On 9/21/26 21:24, Tom Rini wrote:
On Fri, Sep 18, 2026 at 07:42:56PM +0100, Ayoub Zaki wrote:
On 9/18/26 18:53, Tom Rini wrote:
This is interesting and something that does have to be on our radar. My
first question is, should we not just update to a newer mbedtls release
and enable their SHA3-{256,384,512} supports, and anything else we need?
Then we tell people that need this that they need to move from legacy
crypto support to mbedtls (where we get to leverage a wider community
for security audit and response and so on). Thanks!
Hi Tom,
Thanks. I agree with the long-term maintenance benefits. ML-DSA
requires SHAKE128 and SHAKE256 rather than just fixed-output SHA3.
The TF-PSA-Crypto ML-DSA integration is marked experimental in the
Mbed TLS 4.2 documentation.
For this series I would prefer to retain the Linux kernel-based
implementation with limited U-Boot adaptations. A migration to
Mbed TLS could follow as its ML-DSA support matures.
Would that be acceptable?
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.
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.
Let’s revisit the PQC approach once we have more information on the roadmap.
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
VAT No. : DE313902634
