host: Linux 6.18.44-fc-v24 x86_64 | rustc: rustc 1.94.1 (e408947bf 2026-03-25) | 2026-09-11T16:14:14Z | commit: 7f0d8d6 | cmd: cargo test --release --features v2-mera --test cnsa_m1_bench -- --ignored --nocapture
nproc: 4 | cpu:  Intel(R) Xeon(R) Processor @ 2.10GHz
-----
    Finished `release` profile [optimized] target(s) in 61m 37s
     Running tests/cnsa_m1_bench.rs (target/release/deps/cnsa_m1_bench-b7121a674636525e)

running 3 tests

==== CNSA Cat-5: four-way COST comparison (host-measured, RELEASE) ====
N=100000 x 115B | AES-256-GCM-SIV seal med 742 ns (ct 136 B) | ML-DSA-87 sign 1.297 ms / verify 0.361 ms
(every value is a COST -> LOWER IS BETTER)

                          unencrypted  AES-encrypted  legacy-PQC-Cat5   8DB(M1)
storage   B/record               115          136           4763        136.07
write     ns/record                0          742        1297398           754
auth-vfy  s / 100k records          0            0           36.1        0.0004

capability matrix:
  unencrypted     encrypted:NO   quantum-safe:NO            per-datum-Cat5:NO   tamper-evident:NO
  AES-encrypted   encrypted:YES  quantum-safe:NO(classical) per-datum-Cat5:NO   tamper-evident:per-record-tag
  legacy-PQC-Cat5 encrypted:YES  quantum-safe:YES           per-datum-Cat5:YES  tamper-evident:YES  (at ~40x storage)
  8DB (M1)    encrypted:YES  quantum-safe:YES           per-datum-Cat5:YES  tamper-evident:YES  (+O(logN) braid)

8DB vs legacy-PQC-Cat5  (higher = our win):
  storage    :      35x less /record
  write      :    1721x less /record
  auth-verify:  100000x less /set
8DB vs plain AES-encrypted  (the honest 'cost of adding Cat-5'):
  storage    : +0.073 B/record (+0.0539%)
  write      : 1.02x of plain-encrypted write
====================================================================

test bench_four_way_unencrypted_encrypted_legacy_trustdb ... ok

==== CNSA 2.0 Cat-5 M1 micro-benchmark (host-measured) ====
provider: MlDsa87Provider (FIPS 204) | N = 100000 records of 115B
unit sign   (ns): med=368228  (min 352606 / max 499134)
unit verify (ns): med=361391  (min 345595 / max 962798)
ML-DSA-87 signature: 4627 bytes | boundary-sig wire: 7332 bytes

STORAGE - signature overhead:
  row-level Cat-5 : 462700000 B (462.7 MB)  [= N x 4627]
  MERA boundary   : 7332 B (one signature)
  => 63107x less signature storage
  single-record bloat: 115B -> 4742B = 4023% overhead

SIGN CPU @ N:
  row-level : 36.823 s  [= N x med sign]
  boundary  : 0.002223 s  (BLAKE3 over N + 1 sign)
  => 16563x less sign CPU

VERIFY CPU @ N (edge / audit):
  row-level : 36.139 s  [= N x med verify]
  boundary  : 0.000355 s  (1 verify)
  => 101762x less verify CPU
===========================================================

test bench_cat5_rowlevel_vs_mera_boundary ... ok

==== plaintext vs classical-encrypted vs PQC: storage / speed / search (RELEASE) ====
N=100000 x 115B records (storage/speed) | N_search=2000 terms (search demo)

ONE-TIME key establishment (paid once per key/session, NOT per record):
  classical KDF (PBKDF2-HMAC-SHA-512, NIST SP 800-132): 708716278 ns, 0 B wire (only the 16-byte salt is public)
  PQC KEM encapsulate (ML-KEM-1024 + X25519 hybrid)   : 149561 ns, 1616 B wire (ml_kem_ciphertext 1568 B + wrapped_key 48 B)
  PQC KEM decapsulate (recipient side)                : 148941 ns
  => PQC key-establishment wire overhead amortized over N=100000 records: 0.012336% of total dataset size

PER-RECORD storage + speed (AEAD held IDENTICAL across classical & PQC):
                        plaintext   classical-encrypted   PQC (ours)
  storage  B/record           115                   131          131
  write    ns/record            0                   733          737
  read     ns/record            0                   717          716
  => PQC adds 0.0000% storage and 0.5457% write latency vs classical (same AEAD; the only PQC cost is the one-time KEM above)

SEARCH -- can we query the data in each state, and how fast:
  plaintext            : 2080 ns  (1 hits / 2000 terms, direct in-memory index)
  classical-encrypted   : 1285164 ns  (1 hits / 2000 terms) -- NO purpose-built encrypted index exists for this path; this is a full decrypt-and-scan (the only secure option -- a plaintext side-index would leak)
  PQC (ours)            : 374843 ns  (1 hits / 2000 terms) -- the search INDEX is itself sealed under the PQC-KEM-established key; one decrypt-the-index op, then native-speed search (search::sealed_content_index)
  => our sealed-index search is 3x faster than the classical decrypt-and-scan at N_search=2000
=================================================================================

test bench_plaintext_vs_classical_vs_pqc_storage_speed_and_search ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 39.09s

EXIT=0