For KERI applications requiring cryptographic strength, only CSPRNG outputs are acceptable, as they provide the security guarantees necessary for key management and identifier derivation.

Cryptographic Properties

Generation Algorithms

Pseudo-random number generation in KERI contexts relies on cryptographically secure algorithms that transform seed entropy into unpredictable output sequences. The GLEIF Identifier Governance Framework mandates that all AID generation must use either:

• Cryptographically-secure pseudo-random number generators (CSPRNG)
• True random number generators (hardware-based entropy sources)

Both must provide at least 128 bits of cryptographic strength, which represents the minimum entropy required to resist practical brute-force attacks. This 128-bit threshold is derived from information-theoretic security principles, where the number of possible keys (2^128) exceeds the computational capacity of any conceivable attacker, including quantum computers using Grover's algorithm (which would still require 2^64 operations).

Security Properties

For a pseudo-random number generator to be considered cryptographically secure, it must satisfy:

1. Unpredictability: Given any sequence of output values, an attacker cannot predict the next value with probability significantly better than random guessing
2. Indistinguishability: The output sequence is computationally indistinguishable from a truly random sequence
3. Forward Security: Compromise of the current internal state does not reveal previous outputs
4. Backward Security: Knowledge of previous outputs does not enable prediction of future outputs without knowing the internal state

These properties ensure that pseudo-random numbers used in KERI key generation cannot be predicted or reproduced by attackers, even if they know the algorithm being used.

Entropy Requirements

The vLEI Ecosystem Governance Framework establishes strict entropy requirements:

• Minimum 128 bits of cryptographic strength for all seed generation
• Seeds must be generated from collision-resistant random sources
• The entropy must be sufficient to provide adequate cryptographic security for the entire chain of trust that depends on the derived identifiers

This entropy requirement applies to:

• GLEIF Root AID generation
• Delegated AID creation
• Key pair derivation for all establishment events

Data Format & Encoding

Seed Representation

In KERI, pseudo-random numbers used as seeds are typically represented in two formats:

1. BIP-39 Mnemonic Format: A 24-word phrase representing the seed entropy

   • Example: broken toddler farm argue elder behind sea ramp cake rabbit renew option combine guilt inflict sentence what desert manage angry manual grit copy hundred
   • Each word encodes 11 bits of entropy
   • 24 words = 264 bits of entropy (256 bits + 8-bit checksum)

2. Raw Binary/Hexadecimal: Direct representation of the entropy bytes

   • Typically 128, 192, or 256 bits
   • Encoded in hexadecimal for human readability
   • Used internally for cryptographic operations

CESR Encoding

When pseudo-random values are used in CESR (Composable Event Streaming Representation) streams, they are encoded with appropriate derivation codes that indicate:

• The cryptographic algorithm used
• The length of the value
• The encoding format (text or binary domain)

For example, a UUID (high-entropy pseudo-random string) in an ACDC uses the u field with CESR-qualified encoding to ensure proper parsing and verification.

Salty Nonce Usage

In ACDC privacy mechanisms, pseudo-random numbers serve as salty nonces (the u field) to prevent rainbow table attacks. These are:

• High-entropy pseudo-random strings (≥128 bits)
• Unique per ACDC instance
• Included in SAID computation to blind the content
• Never reused across different credentials

The XORA (Exclusive Or Accumulator) specification further details how pseudo-random values can be combined using XOR operations to create information-theoretically secure commitments with perfect security properties.

Usage in KERI/ACDC

Key Pair Generation

The primary use of pseudo-random numbers in KERI is key pair derivation:

1. Seed Generation: A CSPRNG produces a high-entropy seed
2. Private Key Derivation: The seed is processed through a one-way function to generate the private key
3. Public Key Derivation: The private key is processed to generate the corresponding public key
4. Identifier Derivation: The public key (or its digest) becomes the self-certifying identifier

This process is formalized as:

Seed (pseudo-random) → Private Key → Public Key → AID

Inception Event Creation

When creating an inception event for a new AID, pseudo-random numbers are used to:

• Generate the current key pair for signing authority
• Generate the next (pre-rotated) key pair for rotation authority
• Create cryptographic digests of the next keys for pre-rotation commitment

The GLEIF Identifier Governance Framework mandates that both key sets must be generated from pseudo-random sources with at least 128 bits of cryptographic strength.

ACDC Privacy Protection

In ACDC credentials, pseudo-random numbers enable graduated disclosure mechanisms:

• Private ACDCs include a u field containing a high-entropy pseudo-random UUID
• This UUID acts as a salty nonce that blinds the SAID computation
• Without knowledge of the UUID, attackers cannot perform rainbow table attacks to discover the ACDC contents
• The UUID must be ≥128 bits to provide adequate protection

Witness and Watcher Infrastructure

Pseudo-random numbers are used in witness and watcher infrastructure for:

• Generating ephemeral identifiers for one-time-use scenarios
• Creating nonces for challenge-response protocols
• Producing session identifiers for secure communication channels

KRAM Authentication

The KERI Request Authentication Mechanism (KRAM) uses pseudo-random numbers for:

• Nonce generation in authentication requests
• Replay attack protection through unique request identifiers
• Session token creation for stateless authentication

Related Primitives

Relationship to Seeds and Salts

Pseudo-random numbers form the foundation for seeds and salts in KERI:

• Seeds (bran): Pseudo-random values used as primary input for key generation
• Salts: Pseudo-random values added to cryptographic operations to prevent precomputation attacks

Both must be generated from CSPRNG sources to ensure adequate security.

Relationship to Cryptographic Digests

While pseudo-random numbers are inputs to cryptographic processes, digests are outputs:

• Pseudo-random seeds → Key generation → Public keys → Cryptographic digest → SAID
• The digest operation is a one-way function that produces a deterministic output
• Unlike pseudo-random numbers, digests are not generated from seeds but from content

Relationship to Key Pairs

Pseudo-random numbers are the entropy source for key pairs:

• The private key is derived from pseudo-random seed material
• The public key is mathematically derived from the private key
• The security of the key pair depends entirely on the quality of the pseudo-random source

Relationship to Nonces

A nonce (number used once) is a specific application of pseudo-random numbers:

• Generated fresh for each cryptographic operation
• Must be unpredictable to prevent replay attacks
• Used in KRAM for request authentication
• Used in ACDC UUIDs for privacy protection

Implementation Considerations

CSPRNG Selection

Implementers must choose appropriate CSPRNG sources:

Operating System Sources:

• Linux/Unix: /dev/urandom or getrandom() system call
• Windows: CryptGenRandom() or BCryptGenRandom()
• Modern systems provide cryptographically secure random sources by default

Language-Specific Libraries:

• Python: secrets module (not random module)
• JavaScript/Node.js: crypto.randomBytes()
• Rust: rand crate with OsRng backend
• Go: crypto/rand package

Entropy Pool Management

For high-security applications like GLEIF Root AID generation:

• Use hardware random number generators when available
• Ensure adequate entropy pool initialization before key generation
• Consider using multiple entropy sources and combining them
• Implement entropy quality monitoring to detect degraded randomness

Seed Storage and Protection

Pseudo-random seeds used for key generation must be protected:

• Store seeds in encrypted keystores with strong passphrases
• Use hardware security modules (HSM) or trusted execution environments (TEE) for high-value identifiers
• Implement key stretching (e.g., PBKDF2, Argon2) when deriving encryption keys from user passphrases
• Never log or transmit seeds in plaintext

Reproducibility vs. Security Trade-offs

The deterministic nature of pseudo-random numbers creates important trade-offs:

Advantages:

• Key recovery: Seeds can be backed up and used to regenerate key pairs
• Deterministic derivation: Same seed always produces same keys (useful for hierarchical deterministic keys)
• Verifiability: Key derivation can be independently verified

Risks:

• Seed compromise: If the seed is exposed, all derived keys are compromised
• Weak entropy: Poor-quality pseudo-random sources undermine all security
• Predictability: If the algorithm or state is known, future outputs can be predicted

Testing and Validation

Implementations should validate pseudo-random number quality:

• Use statistical test suites (e.g., NIST SP 800-22) to verify randomness properties
• Implement entropy estimation to ensure adequate unpredictability
• Test for bias and correlation in generated sequences
• Verify cryptographic strength meets the 128-bit minimum requirement

Performance Considerations

While CSPRNG operations are generally fast, implementers should consider:

• Batch generation: Generate multiple random values in a single call to reduce overhead
• Caching: For non-security-critical applications, cache pseudo-random values
• Hardware acceleration: Use CPU instructions (e.g., RDRAND on x86) when available
• Avoid blocking: Use non-blocking entropy sources to prevent application stalls

Common Pitfalls

Using Non-Cryptographic PRNGs:

• Never use Math.random(), random.random(), or similar for security-critical operations
• These are suitable for simulations but not cryptography

Insufficient Entropy:

• Ensure at least 128 bits of entropy for all KERI applications
• More entropy (256 bits) provides additional security margin

Seed Reuse:

• Never reuse seeds across different AIDs
• Each identifier must have independent entropy

Predictable Initialization:

• Avoid seeding PRNGs with predictable values (timestamps, process IDs)
• Use operating system entropy sources for initialization

Practical Applications in vLEI Ecosystem

The vLEI Ecosystem relies heavily on pseudo-random numbers:

QVI Credential Issuance

When a Qualified vLEI Issuer (QVI) issues credentials:

1. Generate pseudo-random UUID for each ACDC
2. Use UUID to blind the credential SAID
3. Protect against correlation attacks through high-entropy nonces

Legal Entity Identifier Management

For Legal Entity AIDs:

1. Generate cryptographically secure seed for key pairs
2. Derive transferable identifier with rotation capability
3. Use pseudo-random values for pre-rotation commitments

Multi-Signature Coordination

In multi-sig scenarios:

1. Each signer generates independent pseudo-random key material
2. Threshold signatures combine multiple independent entropy sources
3. No single party can predict or control the collective randomness

This comprehensive treatment of pseudo-random numbers demonstrates their foundational role in KERI/ACDC cryptographic infrastructure, from basic identifier generation to sophisticated privacy-preserving credential systems.

GLEIF vLEI Specific Requirements

• Root AID generation: Must use hardware RNG or highest-quality CSPRNG
• QVI credentials: Each ACDC must have unique pseudo-random UUID (≥128 bits)
• Multi-sig coordination: Each signer must use independent entropy sources
• Witness pools: Minimum 5 witnesses with independent pseudo-random identifier generation