@lib-q/cb-kem 0.0.2

package/README.md

@@ -0,0 +1,303 @@
+# lib-q-cb-kem (Classic McEliece–family CB-KEM)
+
+This directory is the **`lib-q-cb-kem`** workspace crate (see `Cargo.toml`). It vendors/adapts the **classic-mceliece-rust**-style implementation below for use behind the **`cb-kem`** feature of [**lib-q-kem**](../lib-q-kem). In `Cargo.toml`, depend on `lib-q-cb-kem`, not the crates.io name shown in the historical sections of this file.
+
+---
+
+## Upstream-oriented documentation (Classic McEliece)
+
+This is a pure-rust safe-rust implementation of the Classic McEliece post-quantum scheme.
+
+* Classic McEliece is a code-based key encapsulation mechanism (KEM)
+* The implementation is based on the Classic McEliece reference implementation of [NIST round 4](https://csrc.nist.gov/Projects/post-quantum-cryptography/round-4-submissions)
+* The implementation does not utilize any concurrency techniques (SIMD/threading/…, except maybe auto-vectorization on your CPU)
+* It depends on `sha3` as SHA-3 implementation and `aes` as AES block cipher (used as RNG) implementation
+* It passes the 100 testcases of the C reference implementation
+* It implements all 10 variants of the Classic McEliece KEM
+* The implementation takes between 100 milliseconds (`mceliece348864`) and 500 milliseconds (`mceliece8192128f`) to run on a modern computer
+* The implementation is constant-time on software instruction level
+* The random number generator is based on AES256 in counter mode
+* First described in 1978, the cryptographic scheme has a rich history in security analysis. Its large public key size, however, often limits adoption.
+
+The 10 variants have the following designated identifiers:
+
+* `mceliece348864`
+* `mceliece348864f`
+* `mceliece460896`
+* `mceliece460896f`
+* `mceliece6688128`
+* `mceliece6688128f`
+* `mceliece6960119`
+* `mceliece6960119f`
+* `mceliece8192128`
+* `mceliece8192128f`
+
+## Who should use it?
+
+Anyone, how wants to use Classic McEliece to negotiate a key between two parties.
+
+## How does one use it storing keys on the heap (default feature `alloc`)?
+
+Add this to your `Cargo.toml`:
+```toml
+[dependencies]
+lib-q-cb-kem = { version = "0.0.2", path = "../lib-q-cb-kem" }  # from workspace root
+```
+
+To use a specific Classic McEliece variant, you need to import it with the corresponding feature flag:
+
+```toml
+[dependencies]
+lib-q-cb-kem = { version = "0.0.2", features = ["mceliece6960119"] }
+```
+
+Assuming this dependency, the simplest and most ergonomic way of using the library
+is with heap allocated keys and the `*_boxed` KEM step functions. First, we import them:
+
+```rust
+#[cfg(feature = "alloc")]
+use lib_q_cb_kem::{keypair_boxed, encapsulate_boxed, decapsulate_boxed};
+```
+
+Followingly, we run the KEM and provide generated keys accordingly.
+Here, we consider an example where we run it in a separate thread (be aware that the example also depends on the rand crate):
+
+```rust
+#[cfg(feature = "alloc")] {
+  use lib_q_cb_kem::{keypair_boxed, encapsulate_boxed, decapsulate_boxed};
+
+  fn run_kem() {
+    let mut rng = lib_q_cb_kem::LibQRng::new();
+
+    // Alice computes the keypair
+    let (public_key, secret_key) = keypair_boxed(&mut rng);
+
+    // Send `secret_key` over to Bob.
+    // Bob computes the shared secret and a ciphertext
+    let (ciphertext, shared_secret_bob) = encapsulate_boxed(&public_key, &mut rng);
+
+    // Send `ciphertext` back to Alice.
+    // Alice decapsulates the ciphertext...
+    let shared_secret_alice = decapsulate_boxed(&ciphertext, &secret_key);
+
+    // ... and ends up with the same key material as Bob.
+    assert_eq!(shared_secret_bob.as_array(), shared_secret_alice.as_array());
+  }
+
+  fn main() {
+    std::thread::Builder::new()
+      // This library needs quite a lot of stack space to work
+      .stack_size(2 * 1024 * 1024)
+      .spawn(run_kem)
+      .unwrap()
+      .join()
+      .unwrap();
+  }
+}
+```
+
+Pay attention that public keys in Classic McEliece are huge (between 255 KB and 1.3 MB). As a result, running the algorithm requires a lot of memory. You need to consider where you store it. In case of this API, the advantages are …
+
+* you don't need to handle the memory manually
+* on Windows, the call to `keypair` uses more stack than is available by default. Such stack size limitations can be avoided with the heap-allocation API (see Windows remark below).
+
+## How does one use it storing keys on the stack (disabled feature `alloc`)?
+
+The other option is that you exclude the heap-allocation API and use the provided stack-allocation API. Its advantages are:
+
+* stack allocation also works in a `no_std` environment.
+* on some microcontroller platforms, a heap is not available.
+* stack (de-)allocation in general is faster than heap (de-)allocation
+
+Thus, in this section we want to show you how to use this API without the heap. For this, you need to disable feature `alloc` which is enabled per default (this line retains default feature `zeroize` but removes default feature `alloc`):
+
+```toml
+classic-mceliece-rust = { version = "3.0", default-features = false, features = ["zeroize"] }
+```
+
+How does one use the API then (be aware that the example also depends on the rand crate)?
+
+```rust,no_run
+use lib_q_cb_kem::{keypair, encapsulate, decapsulate};
+use lib_q_cb_kem::{CRYPTO_BYTES, CRYPTO_PUBLICKEYBYTES, CRYPTO_SECRETKEYBYTES};
+
+fn main() {
+  let mut rng = lib_q_cb_kem::LibQRng::new();
+
+  // Please mind that `public_key_buf` is very large.
+  let mut public_key_buf = [0u8; CRYPTO_PUBLICKEYBYTES];
+  let mut secret_key_buf = [0u8; CRYPTO_SECRETKEYBYTES];
+  let (public_key, secret_key) = keypair(&mut public_key_buf, &mut secret_key_buf, &mut rng);
+
+  let mut shared_secret_bob_buf = [0u8; CRYPTO_BYTES];
+  let (ciphertext, shared_secret_bob) = encapsulate(&public_key, &mut shared_secret_bob_buf, &mut rng);
+
+  let mut shared_secret_alice_buf = [0u8; CRYPTO_BYTES];
+  let shared_secret_alice = decapsulate(&ciphertext, &secret_key, &mut shared_secret_alice_buf);
+
+  assert_eq!(shared_secret_bob.as_array(), shared_secret_alice.as_array());
+}
+```
+
+Here, you can see how the keys are allocated explicitly.
+
+#### A remark on Windows
+
+If you want your program to be portable with stack allocation and not unexpectedly crash, you should probably run the entire key exchange in a dedicated thread with a large enough stack size. This code snippet shows the idea:
+
+```rust,no_run
+std::thread::Builder::new()
+    .stack_size(4 * 1024 * 1024)
+    .spawn(|| {/* Run the KEM here */})
+    .unwrap();
+```
+
+### libQ Integration
+
+This crate is fully integrated with the libQ cryptography library, providing a secure,
+production-ready implementation of Classical McEliece KEM with comprehensive security validation.
+
+### Feature zeroize: Clear out secrets from memory
+
+If the `zeroize` feature is enabled (it is by default), all key types that contain anything secret
+implements `Zeroize` and `ZeroizeOnDrop`. This makes them clear their memory when they go out of
+scope, and lowers the risk of secret key material leaking in one way or another.
+
+Please mind that this of course makes any buffers you pass into the library useless for reading
+out the key from. Instead of trying to fetch the key material from the buffers you pass in,
+get it from the `as_array` method.
+
+```rust
+#[cfg(not(windows))] {
+    use lib_q_cb_kem::keypair;
+    use lib_q_cb_kem::{CRYPTO_PUBLICKEYBYTES, CRYPTO_SECRETKEYBYTES};
+
+    let mut rng = lib_q_cb_kem::LibQRng::new();
+
+    let mut pk_buf = [0u8; CRYPTO_PUBLICKEYBYTES];
+    // Initialize to non-zero to show that it has been set to zero by the drop later
+    let mut sk_buf = [255u8; CRYPTO_SECRETKEYBYTES];
+
+    // This is the WRONG way of accessing your keys. The buffer will
+    // be cleared once the `PrivateKey` returned from `keypair` goes out of scope.
+    // You should not rely on that array for anything except providing a temporary storage
+    // location to this library.
+    #[cfg(feature = "zeroize")]
+    {
+        let (_, secret_key) = keypair(&mut pk_buf, &mut sk_buf, &mut rng);
+        drop(secret_key);
+        // Ouch! The array only has zeroes now.
+        assert_eq!(sk_buf, [0; CRYPTO_SECRETKEYBYTES]);
+    }
+
+    // Correct way of getting the secret key bytes if you do need them. However,
+    // if you want the secrets to stay secret, you should try to not read them out of their
+    // storage at all
+    {
+        let (_, secret_key) = keypair(&mut pk_buf, &mut sk_buf, &mut rng);
+        assert_ne!(secret_key.as_array(), &[0; CRYPTO_SECRETKEYBYTES]);
+    }
+}
+```
+
+## How does one run it?
+
+This library comes with two examples:
+
+```bash
+$ cargo run --example basic
+```
+
+The output annotates messages with Alice/Bob to illustrate which data is processed by which party.
+The `katkem` example implements the classic request/response file structure which is part of the NIST PQC framework.
+
+In order to validate a generated repsonse file, the corresponding Classic McEliece variant feature flag 
+needs to be passed as `cargo run` parameter.
+
+```bash
+$ cargo run --example katkem PQCkemKAT_935.req PQCkemKAT_935.rsp
+$ cargo run --example katkem PQCkemKAT_935.rsp
+```
+
+The different variants can be enabled through feature flags:
+
+```bash
+$ cargo test --release --features "mceliece6960119" --package lib-q-cb-kem --lib -- tests::test_katkem PQCkemKAT_1450.req PQCkemKAT_1450.rsp
+```
+
+`mceliece348864` is the default variant. You cannot enable two variants simultaneously.
+
+## How fast is it?
+
+All data uses clock cycles as unit (the smaller the better).
+The rust implementation v2.0.0 yielded the following runtime results:
+
+<table>
+  <thead>
+    <tr><td></td><td>complete KEM</td><td>keypair</td><td>enc</td><td>dec</td></tr>
+  </thead><tbody>
+    <tr><td>mceliece348864</td><td>460,062,191</td><td>439,682,143</td><td>222,424</td><td>42,046,357</td></tr>
+    <tr><td>mceliece348864f</td><td>244,943,900</td><td>203,564,820</td><td>215,971</td><td>41,648,773</td></tr>
+    <tr><td>mceliece460896</td><td>1,326,425,784</td><td>1,434,864,061</td><td>487,522</td><td>111,547,716</td></tr>
+    <tr><td>mceliece460896f</td><td>789,636,856</td><td>652,117,200</td><td>553,301</td><td>106,521,703</td></tr>
+    <tr><td>mceliece6688128</td><td>3,188,205,266</td><td>2,596,052,574</td><td>785,763</td><td>202,774,928</td></tr>
+    <tr><td>mceliece6688128f</td><td>1,236,809,020</td><td>1,059,087,715</td><td>826,899</td><td>203,907,226</td></tr>
+    <tr><td>mceliece6960119</td><td>2,639,852,573</td><td>2,532,146,126</td><td>3,864,285</td><td>203,959,009</td></tr>
+    <tr><td>mceliece6960119f</td><td>1,165,079,187</td><td>965,134,546</td><td>3,416,795</td><td>197,089,546</td></tr>
+    <tr><td>mceliece8192128</td><td>3,129,183,262</td><td>2,754,933,130</td><td>965,822</td><td>247,083,745</td></tr>
+    <tr><td>mceliece8192128f</td><td>1,342,438,451</td><td>1,150,297,595</td><td>1,068,317</td><td>242,545,160</td></tr>
+  </tbody>
+</table>
+
+The C reference implementation yielded the following runtime results:
+
+<table>
+  <thead>
+    <tr><td></td><td>complete KEM</td><td>keypair</td><td>enc</td><td>dec</td></tr>
+  </thead><tbody>
+    <tr><td>mceliece348864</td><td>434,103,000</td><td>437,187,000</td><td>187,557</td><td>73,801,300</td></tr>
+    <tr><td>mceliece348864f</td><td>252,423,000</td><td>180,235,000</td><td>189,522</td><td>73,668,000</td></tr>
+    <tr><td>mceliece460896</td><td>760,993,000</td><td>894,497,000</td><td>298,041</td><td>154,507,000</td></tr>
+    <tr><td>mceliece460896f</td><td>606,225,000</td><td>44,906,000</td><td>297,743</td><td>154,013,000</td></tr>
+    <tr><td>mceliece6688128</td><td>1,568,900,000</td><td>1,780,660,000</td><td>425,504</td><td>29,575,000</td></tr>
+    <tr><td>mceliece6688128f</td><td>109,471,000</td><td>760,298,000</td><td>414,358</td><td>298,173,000</td></tr>
+    <tr><td>mceliece6960119</td><td>3,405,730,000</td><td>1,694,410,000</td><td>840,598</td><td>287,154,000</td></tr>
+    <tr><td>mceliece6960119f</td><td>1,311,130,000</td><td>942,987,000</td><td>984,660</td><td>303,543,000</td></tr>
+    <tr><td>mceliece8192128</td><td>1,635,550,000</td><td>760,619,000</td><td>428,112</td><td>361,999,000</td></tr>
+    <tr><td>mceliece8192128f</td><td>1,772,530,000</td><td>1,222,720,000</td><td>534,503</td><td>392,729,000</td></tr>
+  </tbody>
+</table>
+
+The tests were done on a Lenovo Thinkpad x260 (Intel Core i5-6200U CPU @ 2.30GHz). In the case of rust, [criterion 0.3.5](https://crates.io/crates/criterion) has been used as given in `benches/` and in case of C, Google's [benchmark](https://github.com/google/benchmark/blob/v1.6.1/docs/perf_counters.md) with PFM support and disabled CPU frequency scaling. You can run the benchmark suite yourself with the `bench` subcommand and optionally some variant feature flag:
+
+```bash
+$ cargo bench --features mceliece348864
+```
+
+For optimal benchmark results you can run the rust benchmarks with CPU optimization using `RUSTFLAGS="-C target-cpu=native"`, setting the cargo bench optimization profile to `opt-level = 3` and set link time optimizations to `lto = "fat"`. For further insight into the cargo bench settings refer to the official [cargo bench profile](https://doc.rust-lang.org/cargo/reference/profiles.html) documentation.
+
+## Is it correct?
+
+Yes, besides passing unittests (derived from the C implementation), the generated KAT KEM test files have equivalent MD5 hashes. Namely …
+
+<table>
+  <thead>
+    <tr><td>variant</td><td>expected MD5 hash</td></tr>
+  </thead><tbody>
+    <tr><td>mceliece348864</td><td><code>f932d4f75d1a788ad58e7d20af8defe9</code></td></tr>
+    <tr><td>mceliece348864f</td><td><code>70e10264d735abe77a509d853bfc6f6d</code></td></tr>
+    <tr><td>mceliece460896</td><td><code>7d2d60f492a8e74a33696a0616f61746</code></td></tr>
+    <tr><td>mceliece460896f</td><td><code>5ce8c2ecbb8c94082b475ff090f457c4</code></td></tr>
+    <tr><td>mceliece6688128</td><td><code>e7ad02c431ac9019820b7ce96654b240</code></td></tr>
+    <tr><td>mceliece6688128f</td><td><code>39984724cdabb810cdc76ade08a9bf52</code></td></tr>
+    <tr><td>mceliece6960119</td><td><code>819e4a4748f201e47d70f28f5b639303</code></td></tr>
+    <tr><td>mceliece6960119f</td><td><code>59426af22ec3a5e5dddc0969782832a6</code></td></tr>
+    <tr><td>mceliece8192128</td><td><code>9dc71f8a9f8a6492e2b7c341b8a0801b</code></td></tr>
+    <tr><td>mceliece8192128f</td><td><code>8022c8ffd8d938e56840261c91d1e59a</code></td></tr>
+  </tbody>
+</table>
+
+
+
+## Subresource integrity (SHA-384)
+Paths in `integrity-manifest.json` are relative to the package root.

package/integrity-manifest.json

@@ -0,0 +1,6 @@
+{
+  "integrity": {
+    "nodejs/lib_q_cb_kem_bg.wasm": "sha384-WSHdZyuiR5l0+TXBboofuVFeetvxFgp4cgojUeNChpRTNhBJaOhAtzaIMy450xSF",
+    "web/lib_q_cb_kem_bg.wasm": "sha384-WSHdZyuiR5l0+TXBboofuVFeetvxFgp4cgojUeNChpRTNhBJaOhAtzaIMy450xSF"
+  }
+}

package/nodejs/README.md

@@ -0,0 +1,322 @@
+# lib-Q - Post-Quantum Cryptography Library
+
+A Rust cryptography workspace focused on **NIST-standardized post-quantum** key exchange and signatures, **SHA-3-family** hashes and XOFs, and a **transparent STARK**–based zero-knowledge stack. CI enforces `cargo check --workspace --exclude lib-q-examples --exclude lib-q-sca-test --target wasm32-unknown-unknown` (with the `getrandom` wasm_js cfg) so the **publishable library workspace** compiles for the WebAssembly target; npm bundles are produced for the `@lib-q/*` packages listed below (see [docs/npm-packages.md](docs/npm-packages.md)). For build modes, feature flags, and browser baselines, see [docs/wasm-compilation.md](docs/wasm-compilation.md).
+
+## Mission
+
+lib-Q provides a coherent Rust API surface over NIST-track post-quantum primitives, SHA-3–family hashing, Saturnin AEAD, HPKE, and optional STARK-based proofs, with the goal of keeping advanced cryptography approachable without hiding residual implementation risk.
+
+## Key features
+
+- **Post-quantum first**: Post-quantum KEMs and signatures with tiered symmetric options
+- **Standards-aligned**: PQC KEMs and signatures track NIST-standardized modules (e.g. FIPS 203/204/205/206, HQC, Classic McEliece–family CB-KEM); hashes and XOFs use the SHA-3 family; symmetric design centers on Saturnin; ZKPs use a transparent STARK stack (complementary to the NIST PQC algorithm set)
+- **Memory safe**: Built in Rust with zero-cost abstractions
+- **Cross-platform**: Native Rust + WASM compilation
+- **Intuitive API**: Clean, consistent interface designed for modern development
+- **Self-contained algorithms**: No external non-Rust tooling required for core use
+- **Three security tiers**: Ultra-secure, balanced, and performance-optimized options
+- **Modular design**: Use only what you need with individual crates and npm packages
+
+## no_std, embedded, and WebAssembly
+
+- **Umbrella `lib-q` crate**: Disabling default features applies `#![no_std]` to this crate's own code, but some path dependencies are still declared with `std` enabled (for example unified signature support via `lib-q-sig`). The final artifact may still link the standard library. For a **true** `no_std` + `alloc` dependency tree, use the **workspace crates you need** (`lib-q-core`, `lib-q-kem`, `lib-q-ml-dsa`, etc.) with `--no-default-features` and each crate's `alloc` / algorithm features. Per-crate READMEs describe WASM and `no_std` where relevant (for example [lib-q-saturnin/README.md](lib-q-saturnin/README.md)).
+
+- **WASM and `getrandom`**: Match CI when compiling for `wasm32-unknown-unknown`: set `CARGO_TARGET_WASM32_UNKNOWN_UNKNOWN_RUSTFLAGS` to `--cfg getrandom_backend="wasm_js" -C panic=abort` (see [.github/actions/wasm-build/action.yml](.github/actions/wasm-build/action.yml), [scripts/build-wasm.ps1](scripts/build-wasm.ps1), [scripts/security-check.ps1](scripts/security-check.ps1)).
+
+- **`lib-q-zkp`**: Ships a `cdylib` + `wasm` feature for `wasm-pack` / `@lib-q/zkp`; CI also `cargo check`s the ZKP stack on `wasm32-unknown-unknown`.
+
+### Browser example
+
+The minimal browser demo in [`examples/wasm-browser-demo`](examples/wasm-browser-demo) exposes an ML-DSA-44 smoke API:
+
+```javascript
+import init, { wasm_smoke_ml_dsa_sign_verify } from "./pkg/wasm_browser_demo.js";
+
+await init();
+const ok = await wasm_smoke_ml_dsa_sign_verify();
+console.log("ML-DSA wasm smoke:", ok);
+```
+
+## Package structure
+
+lib-Q is organized as a Rust workspace with individual crates and npm packages:
+
+### Rust workspace crates
+
+Publishing to [crates.io](https://crates.io/) is driven by [`.github/workflows/cd.yml`](.github/workflows/cd.yml) in dependency order. The `examples` umbrella and `examples/wasm-browser-demo` are integration harnesses (`publish = false` where set); other members follow `[workspace].members` in [Cargo.toml](Cargo.toml). The workspace-wide WASM compile gate excludes those example crates and `lib-q-sca-test`.
+
+| Crate | Role |
+|-------|------|
+| **`lib-q`** | Umbrella library (feature-gated re-exports) |
+| **`lib-q-types`** | Shared type definitions |
+| **`lib-q-core`** | Core types, traits, provider surface, validation |
+| **`lib-q-keccak`** | Keccak-f / sponge building blocks |
+| **`lib-q-k12`** | KangarooTwelve (K12) |
+| **`lib-q-sha3`** | SHA-3 / SHAKE / cSHAKE core |
+| **`lib-q-keccak-digest`** | Digest adapter over Keccak |
+| **`lib-q-kem`** | KEM façade (ML-KEM, CB-KEM, HQC integration) |
+| **`lib-q-ml-kem`** | ML-KEM (FIPS 203) |
+| **`lib-q-ml-dsa`** | ML-DSA (FIPS 204) |
+| **`lib-q-ring`** | Negacyclic ring / NTT layer for ML-DSA |
+| **`lib-q-sca-test`** | Statistical side-channel harness (TVLA-style) |
+| **`lib-q-lattice-zkp`** | Module-lattice commitments / sigma research |
+| **`lib-q-ring-sig`** | Ring-style openings / DualRing pilots |
+| **`lib-q-prf`** | Legendre / Gold PRF building blocks |
+| **`lib-q-platform`** | Platform helpers |
+| **`lib-q-intrinsics`** | SIMD / intrinsics helpers |
+| **`lib-q-sig`** | Signature façade (ML-DSA, SLH-DSA) |
+| **`lib-q-hash`** | Hash façade (SHAKE, KMAC, TupleHash, etc.) |
+| **`lib-q-aead`** | AEAD façade (Saturnin, Romulus, duplex, tweak) |
+| **`lib-q-saturnin`** | Saturnin suite |
+| **`lib-q-duplex-aead`** | Duplex-sponge AEAD |
+| **`lib-q-tweak-aead`** | Tweakable CTR AEAD over Keccak |
+| **`lib-q-romulus`** | Romulus AEAD (Skinny-based) |
+| **`lib-q-hpke`** | HPKE (RFC 9180) |
+| **`lib-q-utils`** | Shared utilities |
+| **`lib-q-zkp`** | ZKP public API (STARK-backed) |
+| **`lib-q-fn-dsa`** | FN-DSA (FIPS 206) |
+| **`lib-q-slh-dsa`** | SLH-DSA (FIPS 205) |
+| **`lib-q-cb-kem`** | Classic McEliece–family CB-KEM |
+| **`lib-q-random`** | Randomness / entropy helpers |
+| **`lib-q-hqc`** | HQC KEM |
+| **`lib-q-hqc-traits`** | HQC shared traits (`lib-q-hqc/traits`) |
+| **`lib-q-stark`** | STARK prover stack (top-level) |
+| **`lib-q-stark-air`** | AIR definitions |
+| **`lib-q-stark-challenger`** | Fiat–Shamir challenger |
+| **`lib-q-stark-commit`** | Commitment layer |
+| **`lib-q-stark-dft`** | DFT / NTT for STARKs |
+| **`lib-q-stark-field`** | Field arithmetic |
+| **`lib-q-stark-field-testing`** | Field test helpers |
+| **`lib-q-stark-fri`** | FRI |
+| **`lib-q-stark-interpolation`** | Interpolation |
+| **`lib-q-stark-matrix`** | Matrix ops |
+| **`lib-q-stark-mds`** | MDS layer |
+| **`lib-q-stark-merkle`** | Merkle trees |
+| **`lib-q-stark-mersenne31`** | Mersenne-31 field |
+| **`lib-q-stark-monty31`** | Monty-31 field |
+| **`lib-q-stark-rayon`** | Optional Rayon parallelism |
+| **`lib-q-stark-symmetric`** | Symmetric primitives for STARKs |
+| **`lib-q-stark-util`** | STARK utilities |
+| **`lib-q-stark-shake256`** | SHAKE256 bindings |
+| **`lib-q-stark-shake128`** | SHAKE128 bindings |
+| **`lib-q-stark-sha3-256`** | SHA3-256 bindings |
+| **`lib-q-poseidon`** | Poseidon permutation |
+| **`lib-q-plonky-multilinear-util`** | Plonky3 multilinear utilities |
+| **`lib-q-plonky-keccak-air`** | Keccak AIR |
+| **`lib-q-plonky-lookup`** | Lookup argument support |
+| **`lib-q-plonky-uni-stark`** | Univariate STARK |
+| **`lib-q-plonky-batch-stark`** | Batch STARK |
+| **`lib-q-plonky`** | Plonky3-derived integration |
+
+### npm packages (npmjs.com)
+
+These packages are built with `wasm-pack` in CD and correspond to stable JS entry points; other crates are **Rust-only** on crates.io but still participate in the workspace wasm compile gate.
+
+- **`@lib-q/core`** — Umbrella WASM bundle (all algorithms path used in CD)
+- **`@lib-q/ml-kem`** — ML-KEM (FIPS 203) only
+- **`@lib-q/kem`** — Post-quantum KEM façade
+- **`@lib-q/sig`** — Post-quantum signatures (ML-DSA path in CD)
+- **`@lib-q/fn-dsa`** — FN-DSA (FIPS 206)
+- **`@lib-q/hash`** — SHA-3–family hash façade
+- **`@lib-q/utils`** — Utilities
+- **`@lib-q/aead`** — Post-quantum AEAD (Saturnin, Romulus, duplex-sponge)
+- **`@lib-q/hpke`** — Post-quantum HPKE (RFC 9180)
+- **`@lib-q/zkp`** — ZKP / STARK proofs (high-level JSON API)
+- **`@lib-q/random`** — Secure random bytes (`getrandom` / wasm_js)
+- **`@lib-q/hqc`** — HQC KEM
+- **`@lib-q/slh-dsa`** — SLH-DSA (FIPS 205)
+- **`@lib-q/cb-kem`** — Classic McEliece CB-KEM (single compile-time parameter set per build)
+- **`@lib-q/ring-sig`** — Federation / DualRing-LB pilot bindings
+- **`@lib-q/prf`** — Legendre / Gold PRF pilots
+
+## Installation
+
+### Rust (Complete Library)
+```bash
+cargo add lib-q
+```
+
+### Rust (Individual Crates)
+```bash
+# For KEM operations only
+cargo add lib-q-kem
+
+# For signatures only
+cargo add lib-q-sig
+
+# For FN-DSA signatures only
+cargo add lib-q-fn-dsa
+
+# For hash functions only
+cargo add lib-q-hash
+
+# For utilities only
+cargo add lib-q-utils
+```
+
+### Node.js (Complete Library)
+```bash
+npm install @lib-q/core
+```
+
+### Node.js (Individual Packages)
+```bash
+# For ML-KEM only
+npm install @lib-q/ml-kem
+
+# For KEM operations only
+npm install @lib-q/kem
+
+# For signatures only
+npm install @lib-q/sig
+
+# For FN-DSA signatures only
+npm install @lib-q/fn-dsa
+
+# For hash functions only
+npm install @lib-q/hash
+
+# For utilities only
+npm install @lib-q/utils
+
+# AEAD, HPKE, ZKP, RNG, HQC, SLH-DSA, CB-KEM, ring-sig, PRF
+npm install @lib-q/aead @lib-q/hpke @lib-q/zkp @lib-q/random @lib-q/hqc @lib-q/slh-dsa @lib-q/cb-kem @lib-q/ring-sig @lib-q/prf
+```
+
+## Supported algorithms
+
+### Key encapsulation mechanisms (KEMs)
+- **ML-KEM** (FIPS 203; security levels 1, 3, and 5)
+- **CB-KEM** (code-based KEM in the Classic McEliece family; five NIST parameter sets, selectable via crate features)
+- **HQC** (NIST-standardized code-based KEM; parameter sets HQC-128, HQC-192, and HQC-256, corresponding to levels 1, 3, and 5)
+
+### Digital signatures
+- **ML-DSA** (FIPS 204; levels 1, 3, and 5)
+- **FN-DSA** (FIPS 206; levels 1 and 5)
+- **SLH-DSA** (FIPS 205; levels 1, 3, and 5)
+
+### Hash functions
+- **SHAKE256**, **SHAKE128**, **cSHAKE256** (SHA-3 family; used across signatures, KDFs, and protocols)
+- Additional SHA-3–family APIs where exposed by `lib-q-hash` and related workspace crates (see crate documentation)
+
+### Authenticated encryption
+- **Saturnin** (post-quantum symmetric suite: AEAD, block cipher, hash, and stream modes)
+
+### Hybrid public-key encryption (HPKE)
+- **Tier 1: Ultra-Secure** (Pure post-quantum with SHAKE256-based AEAD)
+- **Tier 2: Balanced** (Post-quantum KEM + Saturnin AEAD)
+- **Tier 3: Performance** (Post-quantum KEM + optimized Saturnin)
+
+### Zero-knowledge proofs (ZKPs)
+- **zk-STARKs** (transparent, post-quantum-friendly proof system used in this stack)
+- **Proof generation and verification** via `lib-q-zkp` (built on the workspace STARK crates)
+- **WASM**: `lib-q-zkp` is checked for `wasm32-unknown-unknown` in CI when the relevant features are enabled
+- **Deeper stack**: `lib-q-plonky` and related crates host the Plonky3-derived STARK pipeline (including univariate and batch STARK, Keccak AIR, and lookup support), gated by features for selective compilation
+
+## Architecture
+
+The workspace is centered on the umbrella **`lib-q`** crate and splits algorithms and infrastructure across focused crates. Conceptually:
+
+```
+lib-Q/   (repository root)
+├── lib-q/              # Umbrella library (feature-gated re-exports)
+├── lib-q-core/         # Types, traits, provider surface, validation
+├── lib-q-kem/          # KEM façade and integrations
+├── lib-q-ml-kem/, lib-q-cb-kem/, lib-q-hqc/  # Concrete KEM implementations
+├── lib-q-ring/         # ML-DSA field / NTT shared layer
+├── lib-q-prf/, lib-q-ring-sig/  # PRF pilots + lattice-backed ring-style openings (research)
+├── lib-q-sig/, lib-q-ml-dsa/, lib-q-slh-dsa/, lib-q-fn-dsa/
+├── lib-q-lattice-zkp/  # Module-lattice ZKP research (sigma, commitments)
+├── lib-q-sca-test/     # SCA screening tooling
+├── lib-q-hash/, lib-q-sha3/, lib-q-keccak/, lib-q-k12/
+├── lib-q-aead/, lib-q-saturnin/
+├── lib-q-hpke/
+├── lib-q-zkp/, lib-q-stark*/, lib-q-plonky*/
+├── lib-q-utils/, lib-q-random/, lib-q-platform/, …
+└── examples/
+```
+
+The table above is the authoritative crate list; the `[workspace].members` table in [Cargo.toml](Cargo.toml) is the same set plus the non-published `examples` member.
+
+## Security model
+
+- **Post-quantum asymmetric**: No classical public-key schemes (RSA, ECC, etc.) for those roles; asymmetric modules track NIST PQC (see [SECURITY.md](SECURITY.md)).
+- **Hashes / XOFs**: Cryptographic design targets the SHA-3 family; symmetric constructions center on Saturnin and SHAKE-based options as documented per crate.
+- **Constant-time intent**: Critical paths are written for constant-time behavior; full guarantees require platform-specific review and tooling (see [ROADMAP.md](ROADMAP.md)).
+- **Secure memory**: Sensitive buffers use explicit zeroization where the type system allows.
+- **Side-channel awareness**: Design and review target timing and cache behavior; formal side-channel certification is not yet claimed.
+
+## Development status
+
+**Active development.** Major algorithms are implemented and covered by automated tests; the library remains **pre-production** until independent audit and release hardening (see [SECURITY.md](SECURITY.md)).
+
+### Implemented capabilities
+- **ML-DSA** (FIPS 204; parameter sets ML-DSA-44, ML-DSA-65, ML-DSA-87) with provider-style integration
+- **FN-DSA** (FIPS 206) with CI coverage
+- **SLH-DSA** (FIPS 205) including all twelve SLH-DSA parameter sets
+- **ML-KEM** (FIPS 203; levels 1, 3, and 5)
+- **CB-KEM** (Classic McEliece–family; five parameter sets, feature-selected)
+- **HQC** (HQC-128, HQC-192, HQC-256)
+- **Saturnin** (AEAD, block, hash, stream modes)
+- **HPKE** (RFC 9180) with post-quantum KEM and AEAD options
+- **Hash and XOF suite** (SHA-3 family, including SHAKE and cSHAKE, as exposed by workspace crates)
+- **ZKP / STARK stack** (`lib-q-zkp` and supporting `lib-q-stark*` / `lib-q-plonky*` crates)
+- **Lattice infrastructure** (`lib-q-ring` for ML-DSA field arithmetic; `lib-q-lattice-zkp` for research-grade module-lattice proofs, separate from STARKs)
+- **PRF and ring-style opening pilots** (`lib-q-prf`, `lib-q-ring-sig`; research crates layered on lattice commitments—see per-crate READMEs)
+- **Side-channel tooling** (`lib-q-sca-test` for statistical leakage screening, not a certification claim)
+- **WASM** build paths for core scenarios (see CI and scripts referenced in the [no_std and WASM](#no_std-embedded-and-webassembly) section)
+- **Engineering**: consistent error types, security validation utilities, and GitHub Actions for build, test, coverage, and security checks
+
+### Near-term focus
+- **Performance and ergonomics** for CB-KEM and other large-key KEMs
+- **Assurance**: expanded fuzzing, constant-time verification where feasible, and third-party security review
+- **ZKP**: documentation, API stability, and production-oriented hardening of the STARK pipeline
+
+## Testing
+
+### `lib-q-sig` and SLH-DSA features
+
+`lib-q-sig` separates **algorithm enablement** from **who supplies randomness**:
+
+- **`slh-dsa`**: SLH-DSA with caller-supplied randomness (suitable for `no_std` and tests that pass explicit buffers).
+- **`slh-dsa-std`**: The above plus OS-backed entropy when APIs use `None` for randomness on std targets.
+
+Run crate integration tests accordingly:
+
+```bash
+cargo test -p lib-q-sig --features slh-dsa
+cargo test -p lib-q-sig --features slh-dsa-std
+```
+
+The second command includes end-to-end tests that rely on implicit RNG wiring (`lib-q-random`); the first is appropriate when you only need explicit-randomness coverage.
+
+## Documentation
+
+- [ROADMAP](ROADMAP.md)
+- [Security policy](SECURITY.md)
+- [Security model (technical)](docs/security.md)
+- [ZKP Implementation and Library Layout](docs/zkp-implementation.md) (includes STARK stack and `lib-q-lattice-zkp`)
+- [API Design](docs/api-design.md)
+- [HPKE Architecture](docs/hpke-architecture.md)
+- [Memory Architecture](docs/memory-architecture.md)
+- [Interoperability](docs/interoperability.md)
+- [Entropy Validation](docs/entropy-validation.md)
+- [Test Coverage](docs/test-coverage.md)
+- [AI-Generated Wiki](https://deepwiki.com/Enkom-Tech/libQ)
+
+## License
+
+Apache 2.0 License - see [LICENSE](LICENSE) for details.
+
+## Contributing
+
+We welcome contributions! Please see [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines.
+
+## Security notice
+
+This project ships real cryptographic code but is **not positioned as production-ready**. Treat it as suitable for research, education, interoperability experiments, and internal prototypes until:
+
+- An independent security audit of the code you enable has been completed, and  
+- Your own integration testing, threat modeling, and operational controls are in place.
+
+Absence of a published vulnerability report does not constitute a warranty. Track [SECURITY.md](SECURITY.md) for supported branches, reporting, and update policy.