[...] > >>> > >>> 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 > VAT No. : DE313902634 >
