Sanity check: using saorsa-pqc (Rust) for both ML-KEM and ML-DSA in a messenger app?
I'm building a P2P messenger on Flutter. Current crypto stack is X25519 + ML-KEM-768 hybrid for key agreement, AES-256-GCM for content. The PQ piece is already in place via another library, but I'm evaluating whether to swap implementations before I get too far in.
The candidate is **saorsa-pqc** — a Rust crate that bundles ML-KEM, ML-DSA, and SLH-DSA (FIPS 203/204/205) plus RFC 9180 HPKE in one package. I'd call it from Dart via `flutter_rust_bridge`. What makes it attractive isn't just ML-KEM on its own; it's that if I later want PQ signatures (identity keys, message integrity, etc.), I get ML-DSA from the same library — same audit surface, same dependency to track, HPKE already composed for me so I'm less likely to footgun the primitive composition myself.
Before I commit, two questions for the crowd:
**Has anyone actually looked at saorsa-pqc's implementation quality?** It advertises constant-time ops and secret zeroization, and the API surface looks clean, but it's clearly less battle-tested than liboqs or RustCrypto's separate `ml-kem` / `ml-dsa` crates. For a small-but-real production deployment of a messenger, would you trust it, or stick with PQClean-backed bindings like `pqcrypto`?
**Are there real downsides to bundling KEM + signatures in one library that I'm missing?** My instinct is that the "implementation diversity" argument applies more between hybrid algorithms (which is exactly why I'm running X25519 alongside ML-KEM) than between two NIST primitives sitting inside the same trust boundary — but I'd love to be told why that's naive.
Not a cryptographer, just a dev trying not to footgun. Appreciate any input.