Type Classification

In KERI's taxonomy, a seed is classified as:

• A cryptographic primitive - specifically a serialization of entropy used in cryptographic operations
• A type of salter primitive in the cesride implementation - capable of generating Signer primitives
• The foundational input to the key derivation process that produces self-certifying identifiers

Cryptographic Properties

Entropy Requirements

Seeds must provide sufficient entropy to resist brute-force attacks:

Minimum Entropy: 128 bits of cryptographic strength

• This provides 2^128 possible values
• At 1 million supercomputers performing 1 quadrillion trials per second, brute force would require 8,589,934,592 years
• This security level is considered adequate for post-quantum resistance when used with appropriate key derivation functions

Entropy Sources:

• Cryptographically Secure Pseudorandom Number Generators (CSPRNGs)
• True random number generators (hardware-based)
• User-provided entropy (with appropriate key stretching)

Generation Methods

The KERI documentation distinguishes between two approaches:

1. Hardware Random Number Generators: Produce sequences closer to true randomness, offering higher cryptographic strength
2. Pseudorandom Number Generators: While not truly random, these are important in practice due to:
   • Speed in number generation
   • Reproducibility of sequences (critical for deterministic key derivation)

Derivation Process

The seed undergoes transformation through cryptographic functions:

Seed → Private Key → One-Way Function → Public Key → Identifier

This process ensures:

• Unidirectionality: Cannot derive seed from public key
• Determinism: Same seed always produces same keys
• Collision Resistance: Different seeds produce different keys with overwhelming probability

Data Format & Encoding

BIP-39 Word Representation

Seeds are commonly expressed as mnemonic phrases following the BIP-39 standard:

Example 24-word seed phrase:

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

Properties:

• Each word represents 11 bits of entropy
• 24 words = 264 bits total (256 bits entropy + 8 bits checksum)
• Words selected from standardized 2048-word dictionary
• Includes built-in checksum for error detection

CESR Encoding

In CESR (Composable Event Streaming Representation), seeds are encoded as qualified primitives:

Derivation Code: 0A - Random salt, seed, private key, or sequence number of length 128 bits

Format:

• Text domain: Base64 URL-safe encoding with prepended derivation code
• Binary domain: Raw bytes with binary derivation code prefix
• Must align on 24-bit boundaries for composability

Example CESR-encoded seed:

0AAkG1BmB7xnXBxo2Aasxrq9

This represents:

• 0A = derivation code indicating 128-bit seed
• Remaining characters = Base64-encoded entropy

KERI-Specific: Bran Format

In KERI implementations, particularly Signify, seeds are formatted as bran:

this.bran = MtrDex.Salt_128 + 'A' + bran.substring(0, 21)  // qb64 salt for seed

This format:

• Prepends MtrDex.Salt_128 derivation code
• Adds 'A' character
• Takes first 21 characters of input
• Results in qb64 (qualified Base64) encoding

Usage in KERI/ACDC

Identifier Inception

Seeds are the starting point for creating AIDs:

1. Seed Generation: Create or import seed with sufficient entropy
2. Key Derivation: Derive initial keypair from seed
3. Identifier Creation: Generate self-certifying identifier from public key
4. Inception Event: Create first event in KEL establishing identifier

Key Rotation Support

Seeds enable pre-rotation mechanisms:

• Current Keys: Derived from seed for immediate signing operations
• Next Keys: Pre-rotated keys derived from same seed but different derivation path
• Recovery: If current keys compromised, seed allows generation of pre-committed rotation keys

Multi-Signature Scenarios

In multi-sig configurations:

• Each participant maintains their own seed
• Seeds generate individual keypairs for threshold signing
• No seed sharing required - each controller maintains sovereignty
• Threshold requirements defined in establishment events

Delegation Hierarchies

Seeds support delegated identifiers:

• Root Seed: Generates keys for root AID
• Derived Seeds: Can generate seeds for delegated identifiers
• Hierarchical Structure: Enables organizational key management
• Bivalent Security: Root seed protection extends to delegated identifiers

Credential Issuance

In ACDC credential systems:

• Issuer Seed: Controls issuer AID for signing credentials
• Holder Seed: Controls holder AID for proving possession
• Registry Management: Seed controls TEL registry for issuance/revocation

Related Primitives

Salter Primitive

The salter primitive in cesride:

• Represents a seed value
• Has ability to generate new Signer primitives
• Encapsulates seed with key generation capabilities

Salt vs. Seed Distinction

KERI distinguishes between:

Salt: Random data added to cryptographic operations

• Used in hashing to prevent rainbow table attacks
• May be public or semi-public
• Example: UUID field in ACDC as salty nonce

Seed: Secret entropy for key generation

• Must remain absolutely secret
• Never transmitted or stored unencrypted
• Foundation of identifier control authority

Relationship to Private Keys

Seeds and private keys are related but distinct:

Seed:

• Source entropy
• Can generate multiple private keys
• Stored for recovery purposes
• Never used directly in cryptographic operations

Private Key:

• Derived from seed
• Used for signing operations
• May be ephemeral (regenerated from seed as needed)
• Specific to particular cryptographic algorithm

Security Considerations

Storage Requirements

Seeds require the highest level of protection:

Information-Theoretic Security:

• Seed storage should provide ITPS - the highest level of cryptographic security
• Compromise of seed compromises all derived keys
• No recovery possible if seed is lost

Protection Mechanisms:

• Hardware Security Modules (HSMs)
• Trusted Execution Environments (TEEs)
• Trusted Platform Modules (TPMs)
• Encrypted storage with strong passphrases

Backup and Recovery

SeedQuest Innovation:

The KERI ecosystem includes SeedQuest, a novel approach to seed backup:

• 3D game-based mnemonic system
• Leverages human spatial and episodic memory
• Generates 128-bit entropy through gameplay
• Compatible with BIP-39 conversion
• Addresses the challenge that "human memory is incompatible with long strings of random numbers"

Traditional Backup Methods:

• Physical storage of BIP-39 word lists
• Secret sharing schemes (Shamir's Secret Sharing)
• Multi-location redundant storage
• Encrypted digital backups

Threat Model

Seed Compromise Scenarios:

1. Physical Theft: Attacker gains access to seed storage
2. Digital Extraction: Malware or side-channel attacks
3. Social Engineering: Phishing or impersonation
4. Insider Threats: Authorized personnel misuse

Mitigation Strategies:

• Multi-factor authentication for seed access
• Key stretching for password-derived seeds
• Regular security audits
• Principle of least privilege

Implementation Patterns

Custodial vs. Non-Custodial

Non-Custodial (Recommended):

• User maintains exclusive control of seed
• Highest security and sovereignty
• User responsible for backup and recovery

Custodial:

• Third party holds seed
• Convenience vs. security tradeoff
• Requires trust in custodian
• KERI supports custodial rotation for hybrid models

Seed Generation Best Practices

1. Use Cryptographically Secure Sources: Never use predictable or low-entropy sources
2. Verify Entropy Quality: Test randomness of generation source
3. Secure Generation Environment: Generate seeds on trusted, offline systems
4. Immediate Protection: Encrypt or secure seed immediately after generation
5. Verify Backup: Test seed recovery before relying on it

Key Derivation Patterns

Hierarchical Deterministic (HD) Derivation:

Seed → Master Key → Purpose → Coin Type → Account → Change → Address Index

This pattern enables:

• Multiple identifiers from single seed
• Organizational key management
• Separation of concerns (different keys for different purposes)
• Auditable key usage without exposing seed

Terminology Evolution

Why "Bran"?

Dr. Samuel Smith explains the terminology choice:

"We already use seed and salt for something else so bran is related to seed so we used a term that was evocative of its use but not conflict with already used seed"

This naming convention reflects:

• Precision: Avoiding overloaded terms
• Semantic Clarity: Bran (wheat bran) relates to seeds naturally
• Specification Rigor: Each term has one precise meaning

Cross-Protocol Compatibility

KERI seeds maintain compatibility with:

• BIP-39: Bitcoin Improvement Proposal for mnemonic phrases
• BIP-32: Hierarchical Deterministic Wallets
• SLIP-0010: Universal private key derivation

This enables:

• Interoperability with cryptocurrency wallets
• Reuse of existing key management infrastructure
• Familiar user experience for crypto-native users

Future Directions

Post-Quantum Considerations

Seeds remain relevant in post-quantum cryptography:

• Quantum computers cannot break one-way functions used in key derivation
• Seed-based systems can migrate to quantum-resistant algorithms
• Pre-rotation provides quantum-safe key rotation

Enhanced Backup Mechanisms

Ongoing research includes:

• Biometric-enhanced seed recovery
• Social recovery schemes
• Hardware-backed seed storage
• Distributed seed management

Backup Checklist:

• Write down BIP-39 words in order
• Verify backup by test recovery
• Store in multiple secure locations
• Use tamper-evident storage
• Document recovery procedure
• Test recovery procedure annually

Recovery Testing:

• Perform test recovery on separate system
• Verify derived keys match original
• Confirm identifier control
• Document any issues encountered

KERI-Specific Considerations

Bran Formatting (Signify):

// Correct bran formatting
const bran = MtrDex.Salt_128 + 'A' + userInput.substring(0, 21);
const salter = new Salter({ qb64: bran, tier: tier });

Witness Configuration:

• Generate witness seeds independently
• Use well-known witnesses for testing only
• Rotate witness seeds periodically in production

Delegation Hierarchies:

• Root seed requires highest protection
• Delegated identifier seeds can use lower security
• Document delegation tree structure
• Implement seed rotation policies

Common Pitfalls

Avoid:

• Using Date.now() or Math.random() for seed generation
• Storing seeds in environment variables
• Hardcoding seeds in source code
• Using same seed across multiple systems
• Generating seeds on compromised systems
• Skipping backup verification

Security Anti-Patterns:

• "I'll remember it" - human memory is unreliable
• "It's just for testing" - test seeds leak into production
• "Nobody knows about this system" - security through obscurity fails
• "I'll back it up later" - data loss happens immediately

Performance Considerations

Key Derivation Caching:

• Cache derived keys in memory during session
• Clear cache on logout/timeout
• Never cache seed itself
• Use secure memory (mlock) if available

Batch Operations:

• Derive multiple keys in single operation when possible
• Use HD derivation for related keys
• Minimize seed access frequency

Compliance and Auditing

Audit Trail:

• Log seed generation events (not seed values)
• Track seed access attempts
• Monitor backup operations
• Alert on unusual patterns

Compliance Requirements:

• Document seed management procedures
• Implement access controls
• Maintain backup verification records
• Conduct regular security reviews

Migration and Rotation

Seed Rotation (when necessary):

1. Generate new seed
2. Derive new keys
3. Create rotation event in KEL
4. Update all dependent systems
5. Securely destroy old seed
6. Verify new seed backup

System Migration:

• Export seed in encrypted format
• Verify integrity during transfer
• Import and verify on new system
• Test identifier control
• Securely delete from old system