2. Post-Quantum Cryptography
2.1 Implemented Cryptographic Profiles
The official repository presents ML-DSA-65 and ML-KEM-768 as its primary NIST-standardized post-quantum profile, with SPHINCS+ and a Rescue-Prime + STARK VRF path as additional primitives.
| Code path | Implemented primitive | Role | Status |
|---|---|---|---|
crypto/ml_dsa.rs | ML-DSA-65 | Account, transaction and checkpoint signatures | Implemented |
crypto/kyber_kem.rs | ML-KEM-768-compatible Kyber path | KEM and PQ P2P operations | Implemented |
crypto/vrf_hashbased.rs and VRF modules | Rescue-Prime + STARK hash-based VRF design | Committee randomness and rotation | Implemented design path |
crypto/sphincs.rs | SPHINCS+ | Additional hash-based PQC operations | Implemented |
crypto/signature_aggregation.rs | ML-DSA-oriented aggregation/commitments | Signature-size reduction and attestations | Implemented module |
crypto/* hashing modules | SHA3/SHAKE, BLAKE3 and Merkle constructions | Domain separation, commitments and authenticated data | Implemented |
The L1 manifest explicitly declares pqcrypto-mldsa, pqcrypto-kyber, pqcrypto-sphincsplus, and Winterfell. The implementation should therefore be documented using ML-DSA-65, ML-KEM-768-compatible Kyber, SPHINCS+, and the repository's Rescue-Prime/STARK VRF terminology.
2.2 Transaction and Validator Signatures
Account, transaction and checkpoint signing are documented by the official repository as ML-DSA-65. Validator records also carry the keys required by the VRF and finality paths. The exact key-role separation must follow L1/src/crypto/keypair.rs and the consensus implementation in the official repository.
Signature aggregation in crypto/signature_aggregation.rs uses commitments and Merkle proofs to reduce representation size. It is a compact commitment mechanism; it does not make the underlying post-quantum signatures disappear, and it is not a general-purpose standard aggregate signature scheme.
2.3 P2P Key Establishment
crypto/kyber_kem.rs provides the ML-KEM-768-compatible Kyber KEM path. It supports PQ key establishment and derives session material through the repository's handshake/KDF logic. This role is separate from ML-DSA transaction signatures and must not be conflated with the encrypted-mempool deployment status.
2.4 VRF-Style Committee Selection
The official README describes committee randomness as a Rescue-Prime + STARK hash-based VRF with rotation. The implementation and proof circuit must be read from L1/src/crypto/vrf_hashbased.rs, the VRF modules and Winterfell code in the official repository.
2.5 Scope and Limitations
PQC primitives do not by themselves prove consensus safety. Key custody, parameter choices, serialization, domain separation, implementation correctness, side-channel resistance, proof soundness, deployment configuration and migration procedures remain separate security obligations.