The salter's role is distinct from other primitives: while Signers perform actual signing operations and Verfers verify signatures, the salter operates at a higher abstraction level, managing the seed material from which multiple Signers can be deterministically derived.

Cryptographic Properties

Seed Representation and Entropy

The salter encapsulates a cryptographic seed, which is fundamentally a high-entropy pseudorandom value. According to Document 5, the seed material (referred to as bran in KERI terminology) serves as "a cryptographic string used as a primary input, a seed, for creating key material for an autonomic-identifier."

The security of the salter depends on the entropy quality of its underlying seed. KERI implementations typically require seeds with ≥128 bits of entropy to achieve cryptographic strength sufficient for information-theoretic security against brute-force attacks.

Deterministic Key Derivation

The salter implements deterministic key derivation, meaning that given the same seed input, it will always generate the same sequence of Signer primitives (private keys). This property is critical for:

• Key recovery: The same seed can regenerate all derived keys
• Backup simplicity: Only the seed needs to be backed up, not individual keys
• Hierarchical key management: Multiple keys can be derived from a single seed
• Reproducibility: Key generation is deterministic and verifiable

The deterministic nature follows principles similar to hierarchical deterministic keys (HD keys) used in cryptocurrency wallets, though KERI's implementation is protocol-specific.

Cryptographic Algorithms

While the source documents do not specify the exact key derivation function (KDF) used by the salter, KERI implementations typically employ industry-standard algorithms such as:

• HKDF (HMAC-based Key Derivation Function) for extracting and expanding key material
• PBKDF2 or Argon2 for key stretching when deriving from user-provided passphrases
• Ed25519 or other elliptic curve algorithms for the actual signing keys generated

The salter abstracts these implementation details behind a consistent interface, allowing different cryptographic backends while maintaining API compatibility.

Data Format & Encoding

CESR Encoding Structure

As a CESR primitive, the salter follows CESR's composable encoding scheme. According to Document 4, all cesride primitives share common methods for encoding and representation:

• .qb64() - Qualified base64 representation as a string
• .qb64b() - Qualified base64 representation as bytes
• .qb2() - Qualified base-2 (binary) representation as bytes
• .code() - Derivation code indicating cryptographic type
• .raw() - Raw cryptographic material without qualification

The "qualified" encoding means the salter includes a prepended derivation code that specifies:

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

Text Domain Representation

In the text domain, a salter is represented as a Base64 URL-safe encoded string with a prepended derivation code. Document 5 provides a concrete example from the Signify TypeScript implementation:

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

This shows:

• MtrDex.Salt_128 - The derivation code indicating a 128-bit salt
• 'A' - Additional encoding metadata
• 21 characters - The truncated seed material in Base64 encoding

The resulting qualified Base64 string is self-framing, meaning a parser can determine the primitive's type and length without external schema information.

Binary Domain Representation

In the binary domain, the salter uses a more compact representation:

• Derivation code: 1-2 bytes indicating the primitive type
• Seed material: Raw bytes of the seed (typically 16 bytes for 128-bit seeds)

The binary encoding is optimized for storage and transmission efficiency while maintaining the same semantic content as the text representation.

Composability and Stream Processing

The salter's CESR encoding supports composability, meaning:

• Multiple salters can be concatenated in a CESR stream
• Text and binary representations are interconvertible without loss
• Salters can be pipelined with other primitives
• Stream parsers can extract salters atomically using framing codes

This composability is essential for KERI's hierarchical composition architecture, where complex cryptographic operations are built from concatenated primitives.

Usage in KERI/ACDC

Controller Initialization

The primary use case for salters is in controller initialization when creating new AIDs. Document 13 demonstrates this in the KERIpy implementation:

import keri.core.coring as coring
import keri.app.keeping as keeping

with keeping.openKS(name="edy") as kpr:
    salt = coring.Salter().qb64
    mgr = keeping.Manager(ks=kpr, salt=salt)
    verfers, _, _, _ = mgr.incept(icount=1, ncount=0)

This code shows:

1. Salter creation: coring.Salter() instantiates a new salter with random seed
2. Qualified encoding: .qb64 extracts the Base64 representation
3. Manager initialization: The salt is passed to a key management component
4. Key inception: The manager uses the salter to derive initial keys

The salter enables the inception event by providing the seed material for generating the initial key pair that establishes control authority over the new AID.

Hierarchical Key Derivation

Salters support hierarchical key derivation for creating multiple keys from a single seed. This is critical for:

• Pre-rotation: Deriving next keys before they're needed
• Multi-sig configurations: Generating multiple signing keys
• Delegation hierarchies: Creating delegated identifier keys
• Key rotation: Deriving new keys during rotation events

The hierarchical approach follows the principle that a single high-entropy seed can securely generate an unlimited number of derived keys, each cryptographically independent but deterministically reproducible from the original seed.

Integration with Bran

In KERI terminology, the seed material input to a salter is called bran. Document 5 explains that "bran" was chosen to avoid conflicts with existing uses of "seed" and "salt" in KERI, while maintaining semantic connection to seed-related concepts.

The Signify TypeScript implementation shows the bran-to-salter workflow:

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 demonstrates:

• Bran input: User-provided seed string
• Formatting: Conversion to qualified Base64 format
• Salter instantiation: Creating the salter primitive from formatted bran
• Tier parameter: Security tier for key storage (hardware, software, etc.)

Keystore Integration

Salters integrate with KERI's keystore infrastructure for secure seed storage. Document 13 shows this integration:

with keeping.openKS(name="edy") as kpr:
    salt = coring.Salter().qb64
    mgr = keeping.Manager(ks=kpr, salt=salt)

The keystore (kpr) provides:

• Encrypted storage: Salter seeds are stored encrypted at rest
• Access control: Passcode-protected access to seeds
• Isolation: Separation between seed storage and event logs
• Backup/recovery: Mechanisms for seed backup and restoration

This architecture follows the principle that the salter (seed) is the most critical secret in the system - if compromised, all derived keys are compromised. Therefore, salters receive the highest level of protection in KERI implementations.

ACDC Credential Issuance

While salters are not directly used in ACDC credential structures, they play an indirect role in credential issuance:

1. Issuer key generation: The issuer's signing keys are derived from a salter
2. Signature creation: Derived Signer primitives sign the credential
3. Key rotation: Salters enable key rotation for long-lived issuer identifiers

The salter ensures that credential issuers can maintain consistent control authority over their issuing identifiers while supporting key rotation and recovery.

Related Primitives

Signer Primitive

The Signer primitive is the direct output of a salter's key generation function. According to Document 21, a Signer "represents a private key" and "has the ability to create Sigers and Cigars (signatures)."

The relationship is hierarchical:

• Salter → generates → Signer → creates → Siger/Cigar (signatures)

This hierarchy reflects the cryptographic key lifecycle:

1. Seed (Salter): High-entropy source material
2. Private Key (Signer): Derived signing key
3. Signature (Siger/Cigar): Output of signing operation

Verfer Primitive

The Verfer primitive represents the public key corresponding to a Signer. According to Document 23, a Verfer "represents a public key" and "has the ability to verify signatures on data."

The salter indirectly generates Verfers through the key derivation process:

• Salter → derives → Signer (private key) → paired with → Verfer (public key)

The Verfer is published in inception events and rotation events to establish the key state of an AID.

Diger Primitive

The Diger primitive represents cryptographic digests. According to Document 22, a Diger "represents a digest" and "has the ability to verify that an input hashes to its raw value."

Salters interact with Digers in pre-rotation schemes:

• Salter → derives → Next Signer → public key → Diger (digest of next public key)

The digest of the next public key is committed in the current establishment event, enabling cryptographic binding of future key rotations.

Composition Patterns

Salters participate in several composition patterns:

1. Seed-to-Key Pipeline: Salter → Signer → Verfer
2. Pre-rotation Chain: Salter → Next Signer → Diger (next key digest)
3. Multi-sig Generation: Salter → Multiple Signers (for threshold signatures)
4. Delegation Hierarchy: Root Salter → Delegated Salters (for nested delegation)

These patterns leverage CESR's composability to build complex cryptographic operations from simple primitives.

Implementation Considerations

Seed Generation and Entropy

Implementations must ensure salters are initialized with cryptographically secure random seeds. Document 9 emphasizes that KERI's security depends on cryptographic strength of seed material.

Best practices include:

• Use CSPRNG (Cryptographically Secure Pseudorandom Number Generator)
• Minimum 128 bits of entropy for production systems
• Consider 256 bits for post-quantum security
• Avoid user-generated seeds without proper key stretching

Seed Storage and Protection

Salter seeds are the root secret of the entire key hierarchy and require maximum protection:

• Encryption at rest: Store seeds encrypted with strong passcodes
• Hardware security: Consider HSM or TEE for high-value identifiers
• Backup procedures: Implement secure seed backup and recovery mechanisms
• Access control: Limit seed access to essential operations only

Document 9 notes that "security responsibility lies with the controller, who must protect these functions using best practices appropriate to their security requirements."

Key Derivation Paths

Implementations should define clear key derivation paths for different purposes:

• Inception keys: Path for initial key pair
• Rotation keys: Paths for subsequent rotations
• Delegation keys: Paths for delegated identifiers
• Multi-sig keys: Paths for threshold signature participants

Clear derivation paths enable:

• Reproducible key generation
• Organized key management
• Simplified backup/recovery
• Audit trails for key usage

Performance Considerations

Key derivation from salters can be computationally expensive, especially with key stretching algorithms. Implementations should:

• Cache derived keys: Avoid re-deriving keys unnecessarily
• Lazy derivation: Derive keys only when needed
• Batch operations: Derive multiple keys in a single operation when possible
• Hardware acceleration: Use cryptographic accelerators when available

Testing and Validation

Salter implementations require rigorous testing:

• Determinism tests: Verify same seed produces same keys
• Entropy tests: Validate seed randomness quality
• Encoding tests: Verify CESR encoding/decoding correctness
• Interoperability tests: Ensure cross-implementation compatibility

Document 13 mentions "well-known witnesses" that use predictable salts for testing purposes, but emphasizes these are "for testing purposes only" and should never be used in production.

Security Properties

Information-Theoretic Security

When properly implemented with sufficient entropy, salters provide information-theoretic security - the highest level of cryptographic security. This means:

• Brute-force resistance: 128-bit seeds require 2^128 operations to crack
• Quantum resistance: Sufficient entropy resists quantum attacks on key derivation
• Forward secrecy: Compromise of derived keys doesn't reveal the seed

Key Compromise Recovery

Salters enable key compromise recovery through pre-rotation:

1. Salter derives current and next keys
2. Current key is used for signing
3. Digest of next key is committed in events
4. If current key is compromised, rotate to pre-committed next key
5. Salter derives new next key for future rotation

This mechanism, described in Document 9, provides "compromise recovery protection" that maintains security even after key exposure.

Threshold Security

For multi-sig configurations, salters can generate keys for threshold signature schemes:

• M-of-N signatures: Require M signatures from N possible signers
• Weighted thresholds: Different keys have different voting weights
• Fractional thresholds: Support fractional weight calculations

The salter's deterministic derivation ensures all threshold participants can independently generate their keys from their respective seeds.

Conclusion

The salter primitive is a foundational component of KERI's cryptographic infrastructure, serving as the bridge between high-entropy seed material and operational signing keys. Its role in deterministic key derivation, hierarchical key management, and secure seed storage makes it essential for creating and managing autonomic identifiers with strong cryptographic root-of-trust.

By encapsulating seed material in a standardized CESR primitive with clear encoding and generation capabilities, the salter enables KERI implementations to achieve information-theoretic security while maintaining the flexibility needed for diverse deployment scenarios - from mobile wallets to enterprise HSM configurations.

Testing and Validation

• MUST test determinism (same seed → same keys)
• MUST validate entropy quality of generated seeds
• MUST verify CESR encoding/decoding correctness
• MUST ensure cross-implementation interoperability
• MAY use predictable salts for testing but MUST mark as test-only

Performance Considerations

• SHOULD implement lazy key derivation (derive only when needed)
• SHOULD support batch key derivation operations
• MAY use hardware cryptographic accelerators when available
• SHOULD minimize key re-derivation through caching

Security Best Practices

• MUST follow principle of least privilege for seed access
• MUST implement audit logging for seed usage
• SHOULD support key compromise recovery through pre-rotation
• MUST protect against timing attacks in key derivation
• SHOULD implement secure memory handling (zeroing, locking) for seed material