Finished `release` profile [optimized] target(s) in 10.66s
     Running tests\cnsa_m1_bench.rs (target\release\deps\cnsa_m1_bench-e1ed2af7086d9071.exe)

running 3 tests

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

                          unencrypted  AES-encrypted  legacy-PQC-Cat5   TrustDB(M1)
storage   B/record               115          136           4763        136.07
write     ns/record                0          700         156500           709
auth-vfy  s / 100k records          0            0           35.7        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)
  TrustDB (M1)    encrypted:YES  quantum-safe:YES           per-datum-Cat5:YES  tamper-evident:YES  (+O(logN) braid)

TrustDB vs legacy-PQC-Cat5  (higher = our win):
  storage    :      35x less /record
  write      :     221x less /record
  auth-verify:  100000x less /set
TrustDB vs plain AES-encrypted  (the honest 'cost of adding Cat-5'):
  storage    : +0.073 B/record (+0.0539%)
  write      : 1.01x 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=155900  (min 148700 / max 422900)
unit verify (ns): med=243900  (min 233900 / max 515300)
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 : 15.590 s  [= N x med sign]
  boundary  : 0.001397 s  (BLAKE3 over N + 1 sign)
  => 11160x less sign CPU

VERIFY CPU @ N (edge / audit):
  row-level : 24.390 s  [= N x med verify]
  boundary  : 0.000326 s  (1 verify)
  => 74839x 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): 597829300 ns, 0 B wire (only the 16-byte salt is public)
  PQC KEM encapsulate (ML-KEM-1024 + X25519 hybrid)   : 103400 ns, 1616 B wire (ml_kem_ciphertext 1568 B + wrapped_key 48 B)
  PQC KEM decapsulate (recipient side)                : 101200 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                   500          500
  read     ns/record            0                   700          600
  => PQC adds 0.0000% storage and 0.0000% 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            : 1000 ns  (1 hits / 2000 terms, direct in-memory index)
  classical-encrypted   : 1075700 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)            : 321300 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 32.12s