aere-docs/AERE-NIST-VALIDATION-STATUS.md

Aere Network: NIST Validation Status of the Post-Quantum Cryptography

Status: living document. Last verified against the repository on 2026-07-19.

1. What this document claims, and what it does not

Aere Network ships native post-quantum cryptographic (PQC) precompiles inside its execution client. This document states, precisely and checkably, the relationship between those implementations and the relevant U.S. National Institute of Standards and Technology (NIST) standards.

What Aere Network claims:

• Aere validates its precompile implementations bit-for-bit against the official NIST test vectors. Where the underlying standard is final, this includes NIST ACVP style vectors (Automated Cryptographic Validation Protocol test data published by NIST). Where the standard is not final, this means the published Known Answer Test (KAT) reference vectors only.
• Each validation runs in two directions: the harness feeds an official valid vector and asserts the precompile ACCEPTS it, and it feeds an official invalid vector (or a crafted byte-flip of a valid one) and asserts the precompile REJECTS it. A one-directional "accepts a good signature" check is not sufficient and is not what we rely on.
• The underlying cryptographic implementation is Bouncy Castle (bcprov-jdk18on-1.83.jar). Aere does not roll its own lattice or hash-based signature math for these schemes.

What this document explicitly does NOT claim:

• It does NOT claim that NIST audits, reviews, endorses, or has any relationship with Aere Network. NIST publishes standards and test vectors. Aere consumes them. That is the whole of the relationship.
• It does NOT claim that Aere holds a NIST certification, a FIPS certificate, or a CAVP or ACVP validation listing. Self-validating an implementation against published vectors is a real and reproducible engineering result. It is NOT the same as a NIST-run validation program certificate, and Aere is not listed on the NIST CAVP or ACVP validation lists.
• It does NOT claim that any external security firm has audited this code. An independent security audit (for example by Trail of Bits or NCC Group) is a separate, funded step that has not yet happened. See Section 4.

In one sentence: this is honest, reproducible self-validation against NIST-published vectors, not a NIST certification and not an external audit.

2. Per-scheme validation status

Notes that apply to the whole table:

• "Standard status" reflects real-world NIST status as of this writing. FIPS 203, 204, and 205 were finalized in August 2024. FIPS 206 (FN-DSA, the standardized form of Falcon) is still in draft and is expected to finalize around 2027.
• Repository paths are relative to the repository root. All five mainnet precompiles activated on Aere Network mainnet (chain 2800) at block 9,189,161. ML-KEM-768 is testnet only and is NOT active on mainnet.

Scheme	NIST standard	Standard status	Vectors we validate against	Where in repo	Honest caveat
ML-DSA-44 (Dilithium2), precompile 0x0AE3	FIPS 204	FINAL (Aug 2024). ACVP vectors exist.	Official NIST ACVP ML-DSA-sigVer-FIPS204 vectors, test group 8 (internal interface, externalMu=false). Accept the valid vector, reject the official crafted-invalid vectors (modified message, bad z, bad commitment, bad hint) plus explicit byte-flips and malformed lengths.	Fixture: aerenew/contracts/test/fixtures/mldsa44-acvp-tg8.json. Harness (subset): aerenew/contracts/test/mldsa44Verifier.test.js. Full 15/15: aerenew/contracts/scripts/test-mldsa-local.js. Native-fork KAT result: aerenew/parallel/combined-fork-binary/logs/nist_kat_bc183.txt (15 match, 0 mismatch).	These are genuine ACVP sigVer vectors, so "ACVP-style validation" is accurate here. It remains self-validation, not a CAVP/ACVP certificate.
SLH-DSA-SHA2-128s (SPHINCS+-SHA2-128s-simple), precompile 0x0AE4	FIPS 205	FINAL (Aug 2024). ACVP vectors exist.	Official NIST ACVP SLH-DSA-sigVer-FIPS205 vectors, test group 31 (internal interface, preHash none). All 14 vectors reproduce NIST's expected testPassed value (accept the valid vectors, reject the invalid ones), plus byte-flip rejects.	Fixture: aerenew/contracts/test/fixtures/sphincs-sha2-128s-acvp-tg31.json. Harness: aerenew/contracts/test/AereSphincsVerifier.test.js. Native-fork KAT result: nist_kat_bc183.txt (14 match, 0 mismatch).	Genuine ACVP sigVer vectors. The fixture records the upstream ACVP-Server file SHA-256 hashes for reproducibility. Still self-validation, not a certificate.
ML-KEM-768, precompile 0x0AE6	FIPS 203	FINAL (Aug 2024). ACVP vectors exist.	Official NIST ACVP ML-KEM-encapDecap-FIPS203 vectors (deterministic encapsulation: given ek and m, assert ciphertext c and shared key k match). README records 25/25.	Fetcher: aerenew/pqc-fork/kat/fetch_acvp_mlkem.py. Runner: aerenew/pqc-fork/kat/MlKemAcvpKat.java. Committed vectors: aerenew/pqc-fork/vectors/mlkem768_acvp.txt. Result: aerenew/pqc-fork/results/kat-results-mlkem.json.	TESTNET ONLY. This precompile is NOT active on Aere mainnet. It was built and KAT-verified on an isolated single-validator QBFT testnet. Mainnet activation is founder-gated and has not happened.
SHAKE256, precompile 0x0AE5	FIPS 202	FINAL (long-standing). KAT/ACVP available.	FIPS 202 known-answer digests, for example the empty-string SHAKE256(32) value 0x46b9dd2b...ed5762f and a short-message ("abc") digest. Asserted equal to the FIPS 202 reference output.	Solidity-level assertion in aerenew/contracts/test/AereFalcon512Verifier.test.js. On-chain eth_call check: aerenew/parallel/combined-fork-binary/scripts/check5_precompiles.py. Native-fork KAT result: nist_kat_bc183.txt (4 match, 0 mismatch).	What is committed and asserted here is a small set of FIPS 202 KAT digests, not the full NIST ACVP SHA-3/SHAKE test-group suite. Described honestly as KAT. [VERIFY: if a claim of full ACVP SHAKE coverage is ever wanted, commit and run the complete NIST ACVP SHA-3 vector set.]
Falcon-512, precompile 0x0AE1; Falcon-1024, precompile 0x0AE2	FIPS 206 (FN-DSA)	DRAFT / NOT FINALIZED (expected around 2027). No official ACVP path yet.	Round-3 / reference Known Answer Test vectors only (the official Falcon reference falconNNN-KAT.rsp from the round-3 submission). Accept the official KAT signature and a second KAT vector, reject a tampered signature, a tampered message, a tampered signed-message blob, and a valid signature under the wrong public key.	Falcon-512 fixture: aerenew/contracts/test/falcon512_kat0.json; harness: aerenew/contracts/test/AereFalcon512Verifier.test.js. Falcon-1024 fixture: aerenew/contracts/test/falcon1024_kat0.json; harness: aerenew/contracts/test/AereFalcon1024Verifier.test.js. Native-fork KAT result: nist_kat_bc183.txt (valid + reject for both).	HONEST KEY POINT. There is no final FN-DSA standard and no official ACVP validation path for Falcon yet. Aere validates Falcon against round-3 / reference KAT vectors only and CANNOT claim FIPS or ACVP validation for Falcon until FIPS 206 finalizes. Do not describe Falcon as "ACVP-validated" or "FIPS-validated" anywhere in public copy.

2.1 The Falcon caveat, stated plainly

Falcon is the largest and most easily misstated item here, so it gets its own paragraph. The scheme that NIST selected and is standardizing as FN-DSA in FIPS 206 is still a draft. Until that document is final, NIST does not publish an ACVP validation suite for it, and no CAVP or ACVP certificate for Falcon can exist for anyone, Aere included. What Aere can and does do is validate its Falcon-512 and Falcon-1024 precompiles bit-for-bit against the official Falcon reference KAT vectors from the round-3 submission, in both the accept and reject directions. That is a real correctness check. It is not, and must never be presented as, FIPS or ACVP validation. When FIPS 206 finalizes and NIST publishes FN-DSA ACVP vectors, this row can be upgraded, and not before.

3. Validation method

3.1 Two-directional Known Answer Testing

Every scheme is checked in both directions, because a verifier that returns "accept" for all inputs would pass a one-directional test while being catastrophically broken:

1. ACCEPT direction: feed an official valid vector (public key, message, signature, and where applicable nonce). Assert the precompile returns true (accept).
2. REJECT direction: feed an official invalid vector where NIST expects failure, or take a valid vector and flip a single byte inside the signature, the message, the challenge, or substitute the wrong public key. Assert the precompile returns false (reject).

For the finalized signature schemes (ML-DSA-44 and SLH-DSA-128s) the reject vectors are the actual NIST ACVP negative test cases (modified message, bad z, bad commitment, bad hint, and similar), so the harness reproduces NIST's own expected pass/fail flag for every case rather than only checking hand-made tamperings.

3.2 Where the harness runs

Validation is performed at more than one layer, and all layers must agree:

• Solidity / EVM layer. Hardhat test suites deploy the on-chain verifier contracts and drive them against the committed JSON fixtures. Examples: aerenew/contracts/test/mldsa44Verifier.test.js, aerenew/contracts/test/AereSphincsVerifier.test.js, aerenew/contracts/test/AereFalcon512Verifier.test.js, aerenew/contracts/test/AereFalcon1024Verifier.test.js.
• Native precompile layer. The precompile implementations themselves (Bouncy Castle backed) are exercised by a Java KAT harness on the build box, driven by aerenew/parallel/combined-fork-binary/scripts/run_kat.sh, which compiles and runs the probe against bcprov-jdk18on-1.83.jar. The committed result of that run is aerenew/parallel/combined-fork-binary/logs/nist_kat_bc183.txt: Falcon-512 and Falcon-1024 valid plus reject, ML-DSA-44 15/15, SLH-DSA-128s 14/14, SHAKE256 4/4, zero mismatches.
• Live on-chain layer. After the fork cross, all five mainnet precompiles were exercised by direct eth_call against a running node (aerenew/parallel/combined-fork-binary/scripts/check5_precompiles.py), and a verify-and-record probe wrote accept/reject results into contract state (aerenew/dryrun-results/dryrun/phase_postfork_kat.sh), confirming that an invalid vector reverts on-chain and a valid one records success.

3.3 Underlying implementation

The signature and KEM math is provided by Bouncy Castle, specifically bcprov-jdk18on-1.83.jar, as recorded in run_kat.sh and in the build record aerenew/parallel/combined-fork-binary/BUILD_INFO.txt. Aere's contribution is the EVM precompile plumbing, the calldata encoding, the gas accounting, and the validation harness, not a new implementation of ML-DSA, SLH-DSA, Falcon, ML-KEM, or SHAKE.

4. What this is NOT

This section exists to prevent overclaiming. Each line is a thing an auditor, a bank, or a developer might reasonably ask about, answered honestly.

• This is NOT a NIST certification. NIST has not tested, reviewed, or certified Aere's code. Aere consumes NIST's published standards and test vectors; there is no other relationship, and none is implied.
• This is NOT a CAVP or ACVP validation listing. Aere is not on the NIST Cryptographic Algorithm Validation Program or Automated Cryptographic Validation Protocol validated lists. Passing published ACVP-style vectors in-house is reproducible evidence of correctness; it is not the government-run validation program, and it does not produce a certificate number.
• This is NOT an external code audit. No independent security firm has reviewed this code. The self-validation described here is engineering done by the Aere builders on their own work.
• This is NOT FIPS or ACVP validation for Falcon. FIPS 206 (FN-DSA) is a draft. Falcon is validated against round-3 / reference KAT vectors only, and cannot carry a FIPS or ACVP claim until the standard finalizes (expected around 2027).
• ML-KEM-768 is NOT live on mainnet. It is a testnet-only precompile. Any statement about Aere mainnet PQC must exclude ML-KEM confidentiality.

4.1 The path to an external audit

An independent third-party security audit is a distinct and necessary step that has not yet occurred. It is gated on funding, not on technical readiness. The intended path is a review by an established firm such as Trail of Bits or NCC Group, covering the precompile implementations, the calldata and gas handling, and the surrounding consensus and contract code. When such an audit is commissioned and completed, its scope, date, firm, and findings will be named here explicitly. Until then, this document should be read as self-validation evidence only, and any reader who requires third-party assurance should treat that assurance as pending.

5. Reproduce it yourself

The point of self-validation is that anyone can rerun it. The committed inputs (JSON fixtures and the ML-KEM vector file), the harnesses (Hardhat suites and the Java KAT scripts), and the result logs are all in the repository under aerenew/contracts/test/, aerenew/contracts/scripts/, aerenew/pqc-fork/, and aerenew/parallel/combined-fork-binary/. Reproduction instructions for the fork build and KAT run are in aerenew/pqc-fork/README.md.

---

Appendix A: items flagged for human verification before publishing

• [VERIFY] The native Bouncy Castle KAT harness source (referred to as Probe.java in run_kat.sh) and the flat vector files it consumes (falcon512.txt, falcon1024.txt, mldsa44.txt, slhdsa128s.txt, shake256.txt, expected on the build box at /root/work/probe/ and /opt/aere/besu-pqc-fork/probe/) are NOT committed to this repository. What IS committed is the result log (nist_kat_bc183.txt), the JSON fixtures, the Solidity/JS harnesses, and the run scripts. Decide whether to commit Probe.java and the flat vector files so the native-layer run is fully reproducible from the repo alone.
• [VERIFY] SHAKE256 coverage is described as KAT (a small set of FIPS 202 known-answer digests), not full ACVP SHA-3/SHAKE suite coverage. If a stronger claim is ever wanted, commit and run the complete NIST ACVP SHA-3 vector set first.
• [VERIFY] The Falcon KAT provenance cited in the harness comment is falcon512-KAT.rsp, vector 0, SHA-256 dd75c946...b5cd, reproduced from the round-3 submission. Only the extracted vector-0 (and vector-1) JSON is committed, not the original .rsp file. Confirm the .rsp source hash independently if provenance is challenged.
• [VERIFY] Confirm the block number for mainnet precompile activation (9,189,161) and the precompile addresses 0x0AE1 through 0x0AE5 against the live chain before publishing, and confirm ML-KEM-768 (0x0AE6) and Falcon HashToPoint (0x0AE7) remain testnet only.