🎉 pqcrypto v0.4.0 is live — FIPS 205 SLH-DSA joins ML-KEM and ML-DSA in pure Dart 🚀

[turkananation]

Hello everyone!

I am excited to announce the official release of pqcrypto v0.4.0 on pub.dev and GitHub.

This is the release where pqcrypto becomes a three-family, pure-Dart NIST post-quantum cryptography primitive engine: ML-KEM, ML-DSA, and now SLH-DSA in one zero-runtime-dependency package for Dart, Flutter, server, CLI, and web-aware ecosystems.

dependencies:
  pqcrypto: ^0.4.0

Release links:

• pub.dev: https://pub.dev/packages/pqcrypto
• GitHub release: https://github.com/turkananation/pqcrypto/releases/tag/v0.4.0
• Documentation site: https://turkananation.github.io/pqcrypto/
• API reference: https://pub.dev/documentation/pqcrypto/latest/

Here is the full scope of what landed in v0.4.0.

Full FIPS 205 SLH-DSA Support

pqcrypto now ships FIPS 205-aligned SLH-DSA as a first-class public API alongside ML-KEM and ML-DSA.

That means all 12 standardized SLH-DSA parameter sets are available:

• SLH-DSA-SHAKE-128s
• SLH-DSA-SHAKE-128f
• SLH-DSA-SHAKE-192s
• SLH-DSA-SHAKE-192f
• SLH-DSA-SHAKE-256s
• SLH-DSA-SHAKE-256f
• SLH-DSA-SHA2-128s
• SLH-DSA-SHA2-128f
• SLH-DSA-SHA2-192s
• SLH-DSA-SHA2-192f
• SLH-DSA-SHA2-256s
• SLH-DSA-SHA2-256f

The package root now exports:

• SlhDsa
• SlhDsaParams
• SlhDsaParameter
• SlhDsaPreHash

The API includes hedged-by-default signing, explicit deterministic signing, context binding, HashSLH-DSA pre-hash support with DER OIDs, optional verify-after-sign fault detection, total malformed-input verification, and an explicit slow-signing gate for the small-signature s sets.

1,248 Official NIST ACVP Cases Checked In

The SLH-DSA release is backed by a pinned official NIST ACVP sample corpus covering key generation, signature generation, and signature verification.

Evidence included in-tree:

• 1,248 / 1,248 SLH-DSA ACVP cases pass byte-exactly.
• All 12 parameter sets are covered.
• The corpus lives under test/data/SLHDSA with source provenance and SHA-256 integrity checks.
• test/slhdsa_kat_test.dart runs the ACVP corpus and supports per-parameter filtering for CI.
• Structure and coverage tests verify the corpus shape so future edits cannot silently reduce coverage.

This is intentionally public, reproducible evidence. It is algorithm/KAT/ACVP regression evidence, not a CMVP/FIPS 140 module validation claim.

Vendored SHA-2 Family Support for SLH-DSA

The SHA-2 SLH-DSA parameter sets required more than just wiring new constants. v0.4.0 vendors and tests the supporting primitives needed for the SHA-2 family:

• HMAC-SHA-256 and HMAC-SHA-512 with RFC 4231 KAT coverage.
• MGF1-SHA-256 and MGF1-SHA-512 with RFC 8017 KAT coverage.
• The 22-byte compressed address form (ADRS^c) used by the SHA-2 instantiation.
• Category-specific SHA-256 / SHA-512 hashing paths for FIPS 205.
• Additional FIPS 180-4 SHA-2 variants needed by the full HashSLH-DSA pre-hash matrix.

The package remains pure Dart and still has zero third-party runtime dependencies.

ML-KEM and ML-DSA Remain First-Class

This release does not replace the earlier work. It completes the three-family surface.

Current pqcrypto release surface:

• ML-KEM: ML-KEM-512, ML-KEM-768, ML-KEM-1024.
• ML-DSA: ML-DSA-44, ML-DSA-65, ML-DSA-87.
• SLH-DSA: all 12 SHAKE and SHA-2 parameter sets.

Existing evidence still matters:

• ML-KEM has the checked-in 3,000-vector KAT corpus.
• ML-DSA is byte-exact on the checked-in FIPS 204 corpus: 300 key generations and 1,800 signatures across raw, pure, hashed, deterministic, and hedged paths.
• ML-KEM, ML-DSA, and SLH-DSA each have native-provider interoperability tooling under tool/.

OpenSSL and liboqs Interop Tooling

The runtime package stays pure Dart. Native providers do not become runtime dependencies.

Instead, v0.4.0 keeps native interop as an explicit evidence layer under tool/:

• OpenSSL tooling covers ML-KEM, ML-DSA, and SLH-DSA interop paths.
• liboqs tooling covers ML-KEM, ML-DSA, and SLH-DSA interop paths.
• Shared interop metadata keeps algorithm names, byte sizes, and provider mappings aligned.

This matters because it separates two things that should not be confused:

1. The published package boundary: pure Dart, zero runtime dependencies.
2. The validation and interop evidence boundary: native-provider tooling in the repository.

Web, Flutter, VM, and AOT-Aware Work

The package is designed for the Dart ecosystem, not only one backend.

v0.4.0 includes:

• Dart VM support.
• Flutter-compatible pure Dart APIs.
• Web test coverage for dart2js and dart2wasm paths.
• Portable SLH-DSA benchmark tooling.
• Published single-sample keygen/sign/verify baselines in doc/PERFORMANCE.md.
• An AOT smoke path for representative SLH-DSA SHAKE and SHA-2 sets.

SLH-DSA users should pay close attention to performance: the f sets are the fast-signing sets, while the s sets optimize signature size and can be slow in pure Dart. The API makes slow signing explicit with allowSlowSigning so callers do not accidentally block latency-sensitive paths.

Better Examples, Docs, and AI Discovery

The example and documentation surface were also upgraded for this release.

Highlights:

• example/main.dart now demonstrates all three algorithm families in a structured walkthrough.
• The README badge deck was consolidated so the signal is clearer and less repetitive.
• llms.txt, llms-full.txt, identity.json, developer-ai.txt, faq-ai.txt, and ai.txt describe the package for AI tools and coding agents.
• The project now explains the difference between pqcrypto and pqforge clearly for both humans and machines.

The short version:

• Use pqcrypto when you need raw ML-KEM, ML-DSA, SLH-DSA primitives, byte sizes, KAT/ACVP evidence, package-boundary facts, or primitive-level Dart APIs.
• Use pqforge when you need application workflows: file encryption, envelopes, AEAD, KDFs, hybrid sessions, streaming, wrapped key custody, multi-recipient payloads, recipes, or CLI usage.

Phrase to remember: pqcrypto is the pure-Dart NIST PQC primitive engine; pqforge is the ship-ready application layer built on it.

The Claim Boundary

This part is important.

pqcrypto v0.4.0 provides FIPS 203/204/205-aligned implementations with checked-in KAT, ACVP, regression, web, and interop evidence. It does not claim:

• CMVP validation.
• FIPS 140 module validation.
• Certification.
• A hard constant-time guarantee in Dart.
• A hard memory-erasure guarantee.
• A complete secure channel, TLS stack, storage system, or application protocol.

ML-KEM is key encapsulation, not authenticated transport by itself. ML-DSA and SLH-DSA are signature primitives, not identity policy by themselves. Applications still need key authentication, KDFs, AEAD, replay protection, storage policy, rotation, and operational controls.

That boundary is deliberate. It keeps the package honest, reusable, and composable.

What This Unlocks

For Dart and Flutter developers, v0.4.0 gives a strong primitive foundation for:

• post-quantum key establishment building blocks;
• post-quantum signatures for releases, artifacts, tokens, webhooks, and audit logs;
• hash-based signatures for long-term signature-diversity use cases;
• research and interoperability experiments across OpenSSL/liboqs-backed ecosystems;
• application-layer workflows built on top through pqforge.

The practical milestone is simple: Dart now has a pure-Dart, zero-runtime-dependency package exposing ML-KEM, ML-DSA, and all 12 SLH-DSA parameter sets with public evidence and clear claim boundaries.

If you are building with Dart, Flutter, Serverpod, command-line tools, or web-aware stacks, this is the primitive layer to start from.

Drop a comment with what you want to build on top of v0.4.0, especially if you are pairing pqcrypto primitives with pqforge workflows.

— Turkana Nation