Cryptographic Properties

Entropy Requirements

Bran must provide at least 128 bits of cryptographic strength to ensure collision resistance and security against brute-force attacks. This entropy level provides approximately 2^128 possible values, making exhaustive search computationally infeasible.

Generation Methods

Bran can be generated through:

1. Cryptographically Secure Pseudorandom Number Generators (CSPRNGs): Deterministic algorithms that produce statistically random sequences from high-entropy seeds
2. Hardware Random Number Generators: Physical devices that produce sequences closer to true randomness
3. BIP-39 Seed Phrases: Human-readable word sequences (typically 12 or 24 words) that encode the entropy

Example 24-word seed phrase format:

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

Security Properties

The security of bran relies on:

• Collision resistance: Probability of two different brans producing the same keys is negligible
• One-way derivation: Keys can be derived from bran, but bran cannot be derived from public keys
• Information-theoretic security: When properly generated and protected, bran provides the highest level of cryptographic security

Key Derivation Algorithms

Bran serves as input to key derivation functions that produce:

• Ed25519 keypairs: For digital signatures in KERI events
• X25519 keypairs: For encryption of private keys and next public keys
• Hierarchically deterministic keys: Following patterns similar to BIP-32 for Bitcoin wallets

Data Format & Encoding

CESR Encoding Format

When bran is processed for use in KERI systems, it is converted to CESR (Composable Event Streaming Representation) format. In the Signify TypeScript implementation, this conversion is demonstrated:

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

This transformation:

• Prepends the derivation code MtrDex.Salt_128 to indicate the cryptographic algorithm
• Adds 'A' as part of the CESR encoding structure
• Truncates to 21 characters for the qualified Base64 representation
• Produces a qb64 (qualified Base64) encoded salt suitable for key derivation

Text Representation

Bran is typically represented in human-readable formats:

• BIP-39 word lists: 12 or 24 words from a standardized vocabulary
• Base64 strings: URL-safe encoding for programmatic use
• Hexadecimal: For low-level cryptographic operations

Binary Representation

At the binary level, bran is:

• A sequence of bytes with sufficient entropy
• Typically 128, 256, or 512 bits in length
• Processed through cryptographic hash functions or key derivation functions

Usage in KERI/ACDC

Controller Initialization

In the KERIA (KERI Agent in the cloud) architecture, bran is used during controller initialization:

constructor(bran: string, tier: Tier, ridx: number = 0, state: any | null = null) {
    this.bran = MtrDex.Salt_128 + 'A' + bran.substring(0, 21)  // qb64 salt for seed
    this.stem = "signify:controller"
    this.tier = tier
    this.ridx = ridx
    this.salter = new Salter({ qb64: this.bran, tier: this.tier })
}

This code demonstrates:

• Bran acceptance as a string parameter
• Format conversion to CESR-encoded salt
• Salter initialization using the processed bran
• Key derivation through the Salter mechanism

AID Creation

When creating a new AID, the bran serves as the entropy source for:

1. Inception keys: The initial signing keypair
2. Pre-rotated keys: The next keypair committed via digest
3. Witness configuration: Cryptographic material for witness interactions

Key Rotation

During key rotation events, the bran enables:

• Deterministic generation of new keypairs
• Consistent recovery of rotated keys
• Hierarchical key management across multiple rotations

Multi-Signature Scenarios

In multi-signature configurations, each participant:

• Maintains their own bran
• Derives their portion of the multi-sig keys
• Coordinates signing operations without sharing brans

Delegation Hierarchies

For delegated identifiers, bran enables:

• Parent-child key relationships through hierarchical derivation
• Independent key management at each delegation level
• Recovery capabilities for entire delegation trees

Related Primitives

Relationship to Seed

Bran is explicitly defined as an alias for seed in KERI terminology. According to Dr. Sam Smith, creator of KERI:

"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 choice reflects:

• Semantic relationship: Both bran and seed are grain-related terms
• Disambiguation: Avoids confusion with existing KERI terms
• Functional clarity: Represents raw input material for key generation

Relationship to Salt

While bran is related to cryptographic salts, KERI distinguishes:

• Bran: Primary entropy source for key generation
• Salt: Additional randomness for specific cryptographic operations
• Salter: The KERI primitive that uses bran to generate keys

Relationship to Private Keys

Bran is the precursor to private keys:

• Bran → Key Derivation Function → Private Key → Public Key → AID
• Bran must be protected more carefully than private keys
• Compromise of bran compromises all derived keys

Relationship to Passcode

In some KERI implementations:

• Passcode: User-provided string for authentication
• Bran: Cryptographically strong seed derived from or independent of passcode
• Passcodes may be used to encrypt bran for storage

Implementation Considerations

Security Best Practices

1. Generation: Use CSPRNGs or hardware RNGs for bran generation
2. Storage: Encrypt bran when persisted, never store in plaintext
3. Transmission: Never transmit bran over networks
4. Memory: Clear bran from memory after use
5. Backup: Use secure, offline methods for bran backup

Entropy Quality

Ensure bran has sufficient entropy:

• Minimum 128 bits for standard security
• 256 bits for enhanced security
• Avoid predictable sources (timestamps, sequential numbers)
• Test randomness with statistical test suites

Key Derivation

When deriving keys from bran:

• Use standardized algorithms (PBKDF2, Argon2, scrypt)
• Apply appropriate iteration counts
• Include context-specific information in derivation
• Support hierarchical derivation for key families

Recovery Mechanisms

Implement robust recovery:

• Support BIP-39 word lists for human-readable backup
• Provide clear recovery procedures
• Test recovery processes regularly
• Consider multi-factor recovery options

Cross-Platform Compatibility

Ensure bran handling is consistent:

• Use standard encoding formats (Base64, hex)
• Implement identical key derivation across platforms
• Validate derived keys match across implementations
• Document platform-specific considerations

Terminology Design Rationale

The choice of "bran" as terminology demonstrates KERI's careful approach to specification design:

1. Avoiding Conflicts: KERI already uses "seed" and "salt" for specific purposes
2. Semantic Clarity: "Bran" evokes its seed-related function
3. Memorable: The term is distinctive and easy to remember
4. Unambiguous: No confusion with existing cryptographic terminology

This naming convention reflects the importance of precise, internally consistent vocabulary in cryptographic protocol design, where terminology clarity is essential for correct implementation and security analysis.