1. No reliable distinguishability: No computationally bounded adversary can reliably distinguish the CSPRNG output from a truly random sequence
2. Algorithm transparency: Security holds even when the PRNG algorithm is publicly known and perfectly understood
3. State protection: Only the internal state must remain secret; all other aspects may be public

This contrasts sharply with non-cryptographic PRNGs, which may pass basic statistical randomness tests but can be distinguished from true randomness by an intelligent attacker with knowledge of the algorithm.

Purpose in KERI/ACDC

Within the KERI ecosystem, CSPRNGs fulfill several critical security functions:

• Key pair generation: Creating the asymmetric signing key pairs that establish control authority over AIDs
• Seed generation: Producing the high-entropy seeds from which hierarchically deterministic key derivation occurs
• Salt generation: Creating unpredictable salts for cryptographic operations
• Nonce creation: Generating unique values for replay attack protection in authentication protocols like KRAM
• UUID generation: Producing high-entropy universally unique identifiers for private ACDCs

Cryptographic Properties

Determinism vs. Unpredictability

The apparent paradox of CSPRNGs is that they are simultaneously deterministic and unpredictable:

Deterministic: Given the same internal state (seed), a CSPRNG will always produce the same output sequence. This reproducibility is actually a feature, not a bug—it enables key recovery mechanisms where a user can regenerate their entire key hierarchy from a single backed-up seed phrase.

Unpredictable: Without knowledge of the internal state, the next output value cannot be predicted better than random guessing, even with complete knowledge of all previous outputs and the algorithm itself.

This property is formalized in Document 23 from NIST terminology: "A cryptographic PRNG is a PRNG that is unpredictable when the seed is unknown."

Entropy Requirements

The GLEIF vLEI Ecosystem Governance Framework (Document 28) establishes that all AID generation must use CSPRNGs or true random number generators with at least 128 bits of cryptographic strength. This entropy threshold provides:

• 2^128 possible values (approximately 3.4 × 10^38)
• Collision resistance: Probability of two independently generated seeds colliding is negligibly small
• Brute force resistance: Even with 1 million supercomputers performing 1 quadrillion trials per second, exhaustive search would require approximately 8.6 billion years (Document 43)

Underlying Algorithms

While the KERI specifications do not mandate specific CSPRNG algorithms, common implementations include:

Operating System CSPRNGs:

• /dev/urandom (Linux/Unix)
• CryptGenRandom (Windows)
• SecRandomCopyBytes (macOS/iOS)

Algorithmic CSPRNGs:

• ChaCha20: Stream cipher-based CSPRNG
• AES-CTR: Block cipher in counter mode
• HMAC-DRBG: Hash-based deterministic random bit generator (NIST SP 800-90A)
• Hash-DRBG: Pure hash function-based generator

The critical requirement is that the chosen CSPRNG must be cryptographically analyzed and widely accepted by the security community, not merely statistically random.

Security Properties

CSPRNGs provide several essential security properties:

1. Forward secrecy: Compromise of the current internal state does not reveal previous outputs
2. Backtracking resistance: Knowledge of current output does not enable prediction of previous outputs
3. Prediction resistance: Knowledge of current output does not enable prediction of future outputs (assuming no state compromise)
4. State compromise recovery: After sufficient new entropy is mixed in, the generator recovers security even after state compromise

Data Format & Encoding

Seed Representation

CSPRNG output used for seed generation is typically represented in multiple formats:

Raw Binary: The native output format, typically 128, 256, or 512 bits of entropy

Hexadecimal: Common for technical display and debugging

3a7f8c2e9b1d4f6a8e3c5b7d9f1a4c6e

Base64: Compact representation for storage and transmission

On+MLpsdT2qOPFt9nxpMbg==

BIP-39 Mnemonic: Human-readable word sequences for backup and recovery (Document 4):

broken toddler farm argue elder behind sea ramp 
cake rabbit renew option combine guilt inflict sentence 
what desert manage angry manual grit copy hundred

The BIP-39 standard maps entropy to word sequences from a standardized 2048-word dictionary, where each word represents 11 bits of entropy. A 24-word phrase encodes 264 bits (256 bits of entropy + 8-bit checksum).

CESR Encoding

When CSPRNG-derived values appear in CESR streams (such as in key event logs), they are encoded with appropriate derivation codes:

Private Key Encoding: CESR does not typically transmit private keys, but when stored locally, they use qualified encoding:

• Derivation code indicating key type (e.g., Ed25519, ECDSA secp256k1)
• Base64 URL-safe encoding of the key material
• Appropriate padding for 24-bit boundary alignment

Public Key Encoding: Derived from CSPRNG-generated private keys:

DDSxKwKSZZq672OtzOlokik6L0rr3TtWrZDiHfnATU9j

Where the leading character(s) encode the derivation algorithm.

Seed Encoding: When seeds are stored in KERI keystores, they are encrypted and qualified with codes indicating:

• Encryption algorithm used
• Key derivation function applied
• Salt values (themselves CSPRNG-generated)

Usage in KERI/ACDC

Inception Event Key Generation

The most critical use of CSPRNGs in KERI occurs during inception events when establishing a new AID. The process follows this sequence:

1. Seed Generation: CSPRNG produces high-entropy seed (≥128 bits)
2. Key Derivation: Seed feeds into key derivation function (e.g., HKDF, PBKDF2)
3. Key Pair Creation: Derived material generates asymmetric key pairs
4. AID Derivation: Public key(s) undergo cryptographic hashing to produce the self-certifying identifier

As specified in Document 28, the GLEIF Root AID generation requires:

"An AID must be created from two sets of asymmetric signing key pairs. The key pairs must be generated from either a cryptographically-secure pseudo-random number generator (CSPRNG) or a true random number generator with at least 128 bits of cryptographic strength."

Pre-Rotation Key Generation

KERI's revolutionary pre-rotation mechanism depends on CSPRNG security. When creating an inception or rotation event, the controller:

1. Generates next key pair: Uses CSPRNG to create the key pair that will be used in the next rotation
2. Computes digest: Hashes the next public key to create a commitment
3. Includes in current event: The digest appears in the current event's n (next) field
4. Stores securely: The next private key is stored with highest security, never exposed until rotation

This scheme provides post-quantum security because an attacker who compromises current keys cannot forge a rotation event—they would need to break the one-way hash function to discover the pre-committed next key.

Salt Generation for Private ACDCs

In ACDC credentials, CSPRNGs generate the high-entropy UUID field (u) that serves as a "salty nonce" for private ACDCs. As described in Document 11:

"The UUID, u, field value provides a universally unique identifier that may be used to index or search for the ACDC in a database. When the UUID, u, field is present, the ACDC may be considered a private ACDC."

The UUID must have sufficient entropy (≥128 bits) to prevent rainbow table attacks that could reveal ACDC contents by brute-force enumeration.

Nonce Generation for KRAM

The KERI Request Authentication Method (KRAM) uses CSPRNG-generated nonces for replay attack protection. As detailed in Document 26, each authenticated request includes:

• Timestamp: ISO-8601 formatted datetime
• Nonce: CSPRNG-generated unique value
• Signature: Covering timestamp, nonce, and request body

The nonce ensures that even identical requests at the same timestamp produce different signatures, preventing replay attacks.

Witness and Watcher Infrastructure

CSPRNGs are used throughout the witness and watcher infrastructure:

• Witness AID generation: Each witness requires its own AID with CSPRNG-derived keys
• Receipt signing: Witnesses generate signatures using keys derived from CSPRNG seeds
• Challenge-response protocols: When witnesses validate controller authority, CSPRNG-generated challenges prevent replay

Related Primitives

PRNG (Pseudorandom Number Generator)

A PRNG is the broader category of which CSPRNG is a specialized subset. While all CSPRNGs are PRNGs, not all PRNGs are cryptographically secure. Non-cryptographic PRNGs like Mersenne Twister or Linear Congruential Generators may pass statistical randomness tests but are predictable to attackers who understand the algorithm.

Key Distinction: PRNGs are suitable for simulations, games, and non-security applications. CSPRNGs are mandatory for cryptographic operations where unpredictability is a security requirement.

True Random Number Generators (TRNGs)

TRNGs (also called Hardware Random Number Generators) derive entropy from physical processes:

• Thermal noise in electronic circuits
• Quantum phenomena
• Atmospheric noise
• Radioactive decay

As noted in Document 5:

"Despite the availability of hardware RNGs, pseudorandom number generators (PRNGs) remain important in practice due to: Speed in number generation, Reproducibility of sequences"

In KERI implementations, TRNGs are often used to seed CSPRNGs, combining the true randomness of physical entropy with the speed and reproducibility of algorithmic generation.

Key Derivation Functions (KDFs)

CSPRNGs work in conjunction with Key Derivation Functions like:

• HKDF (HMAC-based KDF)
• PBKDF2 (Password-Based KDF 2)
• Argon2 (Memory-hard KDF)

The typical flow: CSPRNG → Seed → KDF → Key Material → Key Pairs

KDFs stretch and transform CSPRNG output into cryptographic key material with specific properties required by signing algorithms.

Hierarchical Deterministic Key Derivation

CSPRNG-generated seeds enable hierarchical deterministic (HD) key derivation as specified in BIP-32. From a single CSPRNG seed, an entire tree of key pairs can be deterministically derived:

CSPRNG Seed
    |
    v
Master Key
    |
    +-- Child Key 0
    |       |
    |       +-- Grandchild Key 0/0
    |       +-- Grandchild Key 0/1
    |
    +-- Child Key 1
            |
            +-- Grandchild Key 1/0

This enables key reproduction from a single backed-up seed, a critical feature for key recovery in KERI systems.

Implementation Considerations

Seed Storage Security

CSPRNG-generated seeds represent the ultimate root of trust in KERI systems. Their protection requires:

Encryption at Rest: Seeds stored in keystores must be encrypted using:

• Strong symmetric encryption (AES-256-GCM)
• Key derivation from user passphrase (Argon2, PBKDF2)
• Additional CSPRNG-generated salt

Access Control:

• Operating system-level permissions restricting file access
• Hardware Security Module (HSM) storage for high-value identifiers
• Trusted Execution Environment (TEE) for mobile implementations

Backup Procedures:

• BIP-39 mnemonic phrases for human-readable backup
• Secret sharing schemes (Shamir's Secret Sharing) for distributed backup
• Physical security for written mnemonics

Entropy Quality Assurance

Implementations must ensure CSPRNG entropy quality:

Seeding: CSPRNGs must be seeded from high-quality entropy sources:

• Operating system entropy pools (/dev/random, getrandom())
• Hardware RNGs when available
• Multiple entropy sources combined

Reseeding: Long-running processes should periodically reseed CSPRNGs to maintain forward secrecy and recover from potential state compromise.

Testing: Implementations should validate CSPRNG output using statistical test suites:

• NIST Statistical Test Suite (SP 800-22)
• Dieharder test suite
• TestU01 library

Platform-Specific Considerations

Browser Environments: Use window.crypto.getRandomValues() (Web Crypto API)

Node.js: Use crypto.randomBytes() from the built-in crypto module

Python: Use secrets module (not random module) for cryptographic operations

Rust: Use rand crate with OsRng or ThreadRng for cryptographic randomness

Mobile Platforms:

• iOS: SecRandomCopyBytes()
• Android: SecureRandom class

Performance vs. Security Trade-offs

While CSPRNGs are slower than non-cryptographic PRNGs, the performance impact is negligible for KERI operations:

• Key generation: Infrequent operation (inception, rotation)
• Nonce generation: Small values, minimal overhead
• UUID generation: One-time per ACDC

The security benefits vastly outweigh any performance costs. Never use non-cryptographic PRNGs for security-critical operations.

Common Implementation Pitfalls

Insufficient Entropy: Using predictable seeds (timestamps, process IDs) undermines CSPRNG security. Always use OS-provided entropy sources.

Improper Seeding: Seeding with low-entropy values (user passwords without key derivation) provides false security.

State Exposure: Logging or transmitting CSPRNG internal state compromises all future outputs.

Weak Algorithms: Using deprecated or non-cryptographic PRNGs (Mersenne Twister, LCG) in security contexts.

Inadequate Reseeding: Long-running processes that never reseed may become vulnerable to state compromise attacks.

Conclusion

CSPRNGs form the bedrock of cryptographic security in KERI and ACDC systems. Their role in generating unpredictable, high-entropy seeds for key derivation directly determines the security of all downstream operations—from AID control authority to credential issuance and verification. Understanding the distinction between cryptographic and non-cryptographic randomness, implementing proper entropy management, and following security best practices for seed storage are essential for building secure KERI-based identity systems.

Functional Testing:

• Verify key pair generation produces valid signatures
• Confirm seed reproducibility (same seed → same keys)
• Test key derivation paths for HD wallets

Platform-Specific Guidance

Web Browsers:

// CORRECT
const array = new Uint8Array(32);
window.crypto.getRandomValues(array);

// WRONG - NOT cryptographically secure
Math.random();

Node.js:

// CORRECT
const crypto = require('crypto');
const seed = crypto.randomBytes(32);

// WRONG
const random = require('random');

Python:

# CORRECT
import secrets
seed = secrets.token_bytes(32)

# WRONG
import random
random.randbytes(32)  # Not cryptographically secure

Rust:

// CORRECT
use rand::rngs::OsRng;
use rand::RngCore;

let mut seed = [0u8; 32];
OsRng.fill_bytes(&mut seed);

// WRONG
use rand::thread_rng;  // May not be cryptographically secure

Performance Considerations

• CSPRNG operations are infrequent in KERI (inception, rotation)
• Performance impact is negligible compared to signature operations
• Never sacrifice security for performance in CSPRNG selection
• Cache derived keys, not seeds, if performance optimization needed

Security Audit Checklist

• All key generation uses OS-provided CSPRNG
• Minimum 128-bit entropy for all cryptographic seeds
• Seeds encrypted at rest with strong symmetric encryption
• Key derivation uses approved KDFs (HKDF, PBKDF2, Argon2)
• BIP-39 implementation validates checksums
• No seeds or private keys logged or transmitted
• Statistical testing performed on CSPRNG output
• Backup and recovery procedures documented and tested
• HSM/TEE integration for high-security deployments
• Periodic reseeding implemented for long-running processes