On Fri, Sep 18, 2026 at 06:21:23PM +0100, Ayoub Zaki wrote: > Classical signature schemes such as RSA and ECDSA are vulnerable to > attacks by sufficiently powerful quantum computers. This series adds > ML-DSA verification as a first step towards post-quantum cryptography > (PQC) support in U-Boot. > > This RFC adds generic verification support for pure FIPS 204 ML-DSA > without an external message prehash. SHAKE hashing remains part of the > ML-DSA algorithm. HashML-DSA is not supported. See FIPS 204 Section 5.3: > https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf > > It supports ML-DSA-44, ML-DSA-65 and ML-DSA-87. The implementation is > verification-only. It contains no target signing code or private-key > handling. > > This series targets U-Boot proper. SPL support is not included. > Verification allocates approximately 8 to 12 KB of heap workspace > depending on the parameter set and ABI alignment. This excludes > allocator overhead. Any future SPL integration will need to account > for heap availability, stack usage and code size. > > The verifier is adapted from the Linux crypto library implementation. > The series preserves the Linux licensing, copyright notices and source > provenance. Linux facilities are replaced with direct U-Boot equivalents > where needed. > > ML-DSA requires SHAKE128 and SHAKE256. The series adds generic one-shot > and incremental SHAKE interfaces backed by Keccak-f[1600]. This code can > be used by consumers other than ML-DSA. > > The public ML-DSA API accepts raw FIPS 204 public keys, raw signatures > and one contiguous message. > > The tests are based on Linux KUnit tests and cover all three ML-DSA > parameter sets with valid and invalid inputs. SHAKE128 and SHAKE256 > are checked against FIPS 202 known answers. > > Validated with sandbox and qemu_arm64_defconfig builds plus the SHAKE > and ML-DSA unit tests on sandbox. > > This series does not add FIT semantics or mkimage signing. A follow-up > series can add a generic incremental transcript, target FIT verification > and host signing. > > Feedback is welcome on the public API and Kconfig placement.
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!
--
Tom
signature.asc
Description: PGP signature
