Pqrascv-core: Post-quantum (ML-DSA-65) remote attestation with built-in SLSA provenance for no_std embedded Rust

Hello, I would really appreciate your feedback on this project i have been working on.
Two converging threats are making classical attestation obsolete in 2026:

Supply-chain attacks are accelerating. SolarWinds, XZ Utils, and dozens of lesser-known incidents show that firmware can be compromised at build time. Existing attestation stacks (TPM 2.0, DICE, TDX) prove what is running — but carry no cryptographic proof of how it was built or who signed it off.

Post-quantum migration is overdue. RSA and ECDSA underpin today's attestation chains and are broken by Shor's algorithm. NIST finalised ML-DSA (FIPS 204) and ML-KEM (FIPS 203) in 2024. Devices deployed today may still be in service when cryptographically-relevant quantum computers arrive.

PQ-RASCV addresses both in a single embedded-first library. Every attestation quote is post-quantum signed and supply-chain provenance-linked no separately bolted-on components.

The project is completely open source and can be accessed here: GitHub - comwanga/pqrascv-core: Post-Quantum Remote Attestation & Supply Chain Verification · GitHub

The documentation and more details can be viewed here: crates.io: Rust Package Registry

Hello this insane i will check :person_gesturing_ok: im working also on embedded rust with embassy, your project is asynchro or not :thinking:

This is a great idea; I fully support what you're doing. Encrypting/signing anything with pre-quantum methods now is just opening yourself to SNDL attacks without need. I have been looking for a good PQ tool for a while now, and this seems very promising. Thank you, and well done!

Sidenote: Maybe PQ algorithms are needed even earlier - if this improvement over Shor is true: Quantum Decryption of RSA Is Much Closer Than Expected - SecurityWeek

Thanks man :folded_hands: and awesome to hear you're working with embedded Rust + Embassy too.

Right now PQ-RASCV’s cryptographic core is mostly synchronous by design. The measurement, hashing, ML-DSA signing, and verification paths are intentionally blocking/deterministic because they sit inside the trust boundary and I want them to remain easier to audit and safer for "no_std" environments.

The long-term architecture is hybrid though:

  • sync security core
  • async infrastructure layer

So things like:

  • networked verifier services
  • provenance fetching
  • transparency logs
  • Bitcoin anchoring
  • distributed policy evaluation

will likely move to async (Tokio/Embassy depending on environment), while the core attestation primitives stay synchronous.

Also after some deep security review feedback, I'm restructuring the project around real hardware roots of trust (TPM/DICE/TDX/SEV-SNP) rather than positioning the software backend as production attestation.

Really appreciate this :folded_hands:

Yeah, the “harvest now, decrypt later” risk was one of the main motivations behind the project. I wanted to explore PQ attestation + supply-chain verification in a way that could work for embedded systems and sovereign infrastructure.

Got some brutal but valuable security audit feedback recently too, so I’m now redesigning parts of the trust model to make it more production-grade instead of just cryptographically interesting :sweat_smile:

Even if large-scale quantum systems are still years away, long-lived trust systems like firmware signing and infrastructure identity are already exposed to “store now, break later” attacks.

Still early days for the project, but I’m trying to push it toward something actually deployable, not just theoretical.

Great project keep going if you need help don't hésitate i would love to help rust écosystèm , i dont know why so many people hate Rust often c et c++ people so lets make Rust great and safe people deserve safety no More gambling c :person_gesturing_no: