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! /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 > VAT No. : DE313902634 >
