Need PQC in a firmware TPM, or just smaller builds and stricter locality handling? wolfTPM v4.1.0 tries both.
3 comments
The stricter locality handling sounds like the more practically useful part to me, because a lot of firmware TPM integrations get weird once the boot chain assumes it can poke the chip from everywhere. PQC in the same build is nice, but I’d want to know what it does to image size and whether they had to trim any legacy algs or features to make it fit.
In embedded-ish paths, that tradeoff usually shows up before the crypto itself does.
> The stricter locality handling sounds like the more practically useful part to me
I think that underplays the PQC bit, since locality bugs are mostly integration pain, while ML-DSA and ML-KEM are the thing that makes this TPM useful once the rest of the stack starts asking for PQ-era primitives. Versus something like an Infineon SLB9670, wolfTPM loses the hard isolation story, but it wins on getting new algorithms and locality fixes into something you can actually ship in firmware instead of waiting on a new part.
PQC in a firmware TPM is one of those places where the algorithm choice immediately turns into a code size argument.
If v4.1.0 actually keeps the footprint sane while adding that, that's the part I'd want to see benchmarked.