Post-Quantum Cryptography

RougeChain uses NIST-approved post-quantum cryptographic algorithms to protect against both classical and quantum computer attacks.

Why Post-Quantum?

Quantum computers threaten current cryptography:

Algorithms Used

ML-DSA-65 (Digital Signatures)

Formerly: CRYSTALS-Dilithium
Standard: FIPS 204
Security Level: NIST Level 3 (192-bit classical equivalent)

Used for:

• Transaction signatures
• Block proposal signatures
• Validator attestations

Key sizes:

ML-KEM-768 (Key Encapsulation)

Formerly: CRYSTALS-Kyber
Standard: FIPS 203
Security Level: NIST Level 3

Used for:

• Messenger encryption
• PQC Mail encryption
• Future: Encrypted transactions

Key sizes:

SHA-256 (Hashing)

Used for:

• Block hashes
• Transaction hashes
• Merkle trees

While Grover's algorithm reduces SHA-256 security to ~128-bit equivalent against quantum computers, this is still considered secure.

Implementation

RougeChain uses the following libraries:

All cryptographic operations happen locally - private keys never leave your device.

Key Generation

#![allow(unused)]
fn main() {
// Rust example
use pqcrypto_dilithium::dilithium3::*;

let (pk, sk) = keypair();
let signature = sign(message, &sk);
let valid = verify(message, &signature, &pk);
}

// TypeScript example
import { ml_dsa65 } from '@noble/post-quantum/ml-dsa';

const { publicKey, secretKey } = ml_dsa65.keygen();
const signature = ml_dsa65.sign(message, secretKey);
const valid = ml_dsa65.verify(signature, message, publicKey);

Security Considerations

1. Key storage - Private keys are stored in localStorage when no vault password is set (for PWA persistence), or encrypted with AES-256-GCM (PBKDF2, 600K iterations) when the user configures a vault passphrase. Active session keys are held in sessionStorage.
2. Entropy - Keys use cryptographically secure random number generators
3. Side channels - Library implementations are designed to be constant-time
4. Hybrid approach - Consider adding classical signatures for defense-in-depth

zk-STARKs (Zero-Knowledge Proofs)

RougeChain includes a zk-STARK proof system for privacy-preserving transaction verification. STARKs are quantum-resistant by design — they rely only on hash functions, not elliptic curves.

How It Works

The STARK module can prove that a balance transfer is valid (value is conserved, sender has sufficient funds) without revealing the actual balances or transfer amount. The verifier only sees the final balances.

Usage

#![allow(unused)]
fn main() {
use quantum_vault_crypto::stark::{
    prove_balance_transfer, verify_balance_transfer, BalanceTransferInputs,
};
use winterfell::math::{fields::f128::BaseElement, FieldElement};

// Prover (knows private balances)
let proof = prove_balance_transfer(1000, 500, 250).unwrap();

// Verifier (only sees final balances)
let public_inputs = BalanceTransferInputs {
    total_value: BaseElement::from(1500u64),
    final_sender_balance: BaseElement::from(750u64),
    final_receiver_balance: BaseElement::from(750u64),
};
verify_balance_transfer(proof, public_inputs).unwrap();
}

zk-STARK Rollup Batch Proofs (Phase 3)

The rollup system batches multiple transfers into a single STARK proof, dramatically reducing on-chain verification costs.

Rollup AIR (5-Column Trace)

sender_before | sender_after | receiver_after | amount | running_hash

Constraints:

1. Value conservation: sender_after = sender_before - amount
2. Running hash accumulation: hash[i+1] = hash[i] + sender_before[i] * amount[i]
3. Cross-check redundancy

Boundary Assertions: running_hash transitions from pre_state_root to post_state_root

State Root

SHA-256 Merkle tree from sorted account balances with domain separation:

• Leaf: SHA-256("ROUGECHAIN_STATE_V1" || address || balance_le_bytes)
• Node: SHA-256("ROUGECHAIN_NODE_V1" || left || right)

Rollup API

# Check rollup status
curl https://testnet.rougechain.io/api/v2/rollup/status

# Submit transfer to rollup batch
curl -X POST https://testnet.rougechain.io/api/v2/rollup/submit \
  -H "Content-Type: application/json" \
  -d '{"sender":"pubkey1","receiver":"pubkey2","amount":100,"fee":1}'

# Get completed batch result
curl https://testnet.rougechain.io/api/v2/rollup/batch/1

Bridge Verification (STARK Bridge)

Deposits from Base are cryptographically verified before minting:

1. EVM Receipt Verification — tx status, recipient, sender, confirmations
2. SHA-256 Commitment Nullifiers — SHA-256("ROUGECHAIN_BRIDGE_V1" || tx_hash || address || amount) prevents double-claims
3. BridgeDeposit Event Verification — for XRGE vault deposits (log parsing)

Future Roadmap

• zk-STARK proof system (Phase 1: balance transfer AIR)
• zk-STARK Phase 2: shielded transactions on-chain
• zk-STARK Phase 3: ZK-rollup layer
• STARK bridge deposit verification
• Fully trustless STARK bridge (Base light client)
• SLH-DSA (SPHINCS+) as alternative signature scheme
• Hybrid classical+PQC mode
• Hardware wallet support
• Threshold signatures for multi-sig
• WASM-compiled STARK prover for browser (core/wasm-prover/, served as stark-prover.wasm)