Salts must be generated using Cryptographically Secure Pseudorandom Number Generators (CSPRNGs) to ensure unpredictability. The KERI implementation leverages libsodium's random number generation facilities, which provide cryptographically strong entropy sources across multiple platforms. The use of CSPRNGs rather than basic PRNGs is critical - basic pseudorandom generators may pass statistical tests but can be distinguished from true randomness by intelligent attackers.

Key Derivation Integration

When used for key derivation, salts are processed through key stretching algorithms such as Argon2id (implemented via libsodium's crypto_pwhash API). These memory-hard functions combine the salt with the user's passphrase through computationally intensive operations that resist GPU and ASIC-based attacks. The Argon2id algorithm provides:

• Memory-hard properties that make parallel attacks expensive
• Tunable computational cost via opslimit and memlimit parameters
• Backward compatibility guarantees across libsodium versions
• Resistance to side-channel attacks through constant-time operations

The key derivation process produces Ed25519 signing key pairs and X25519 encryption key pairs from the salt-bran combination. The deterministic nature means the same salt and bran will always produce identical keys, enabling key recovery from backed-up credentials without storing private keys directly.

Blinding Factor Properties

In ACDC credentials, salts function as blinding factors that hide credential content from correlation attacks. The high-entropy salt (typically 128 bits or more) is combined with credential attributes before hashing, ensuring that even identical attribute values produce different hashes across different credentials. This prevents:

• Rainbow table attacks where adversaries precompute hashes of common values
• Statistical correlation between credentials with similar attributes
• Linkability attacks that track credential usage across contexts

The Salty Nonce Blinding Factor mechanism in Blindable State TELs (Transaction Event Logs) extends this concept to credential state management. Three cryptographic approaches are specified:

1. HTOP (HMAC-Based One-Time Password) per RFC 6238 for secret sharing
2. TOTP (Time-Based One-Time Password) for time-synchronized access control
3. HDKM (Hierarchical Deterministic Key Management) for structured key derivation

These mechanisms enable selective state disclosure where credential holders can control which verifiers can observe credential state (issued, revoked, suspended) by sharing or withholding the blinding salt.

Data Format & Encoding

CESR Representation

Salts in KERI are encoded as CESR (Composable Event Streaming Representation) primitives, ensuring consistent representation across text and binary domains. The CESR encoding includes:

• Derivation code prefix indicating the salt type and length
• Base64 URL-safe encoding for text domain representation
• Raw binary encoding for compact transmission
• Self-framing properties enabling stream parsing without delimiters

A typical salt encoding uses the 0A derivation code for "Random salt, seed, private key, or sequence number of length 128 bits." The CESR primitive structure ensures that salts can be:

• Concatenated with other primitives in streams
• Converted between text and binary domains without loss
• Parsed atomically from event streams
• Verified for type and length correctness

Storage and Transmission

Salts are stored in multiple contexts within KERI infrastructure:

Keystore Initialization: During kli init operations, salts are generated and stored in the keystore configuration. The vLEI ecosystem governance framework treats salts as equivalent in importance to private keys, requiring protection through:

• Encrypted storage in keystores
• Secure backup mechanisms (1Password, macOS Keychain)
• Access control independent of controller keys
• Audit logging of salt access operations

ACDC UUID Fields: The u field in ACDC credentials contains a salt encoded as a high-entropy pseudorandom string. This field:

• Appears in both compact and uncompacted ACDC variants
• Is included in the SAID computation for the credential
• Provides correlation resistance across credential presentations
• Enables private ACDC variants through content blinding

Configuration Files: For testing and development, salts may appear in configuration files, though the vLEI governance framework explicitly warns that "storing salts in configuration files is highly insecure" for production deployments. The --insecure flag in KERI tools writes salts to filesystem in plaintext for development only.

Well-Known Witnesses

A special case exists for well-known witnesses used in testing environments. These witnesses use predetermined salts to initialize keystores, enabling predictable identifier generation for reproducible test scenarios. The documentation explicitly warns: "For testing purposes only! Never use well-known witnesses in production." The predictability that makes them useful for testing creates security vulnerabilities in production where witness identifiers must be cryptographically random.

Usage in KERI/ACDC

Keystore Initialization

The primary usage of salts in KERI is during keystore initialization via the kli init command:

kli init --name keystore_name --passcode <passcode> --salt <salt>

The salt parameter accepts a CESR-encoded random value, typically generated via kli salt. This salt, combined with the keystore's aeid (authentication encryption identifier) and the user's passcode, deterministically generates all key pairs for identifiers created in that keystore. The initialization process:

1. Generates or accepts a CESR-encoded salt
2. Combines salt with passcode through Argon2id key derivation
3. Produces master key material for the keystore
4. Derives individual key pairs for each AID created
5. Stores encrypted key material in the keystore database

Signify Client Initialization

In the Signify signing-at-the-edge architecture, salts play a critical role in client initialization. The SignifyClient constructor accepts a bran parameter (passphrase), which is processed with a salt to derive the Client AID:

const bran = randomPasscode();
const client = new SignifyClient(adminUrl, bran, Tier.low, bootUrl);

Internally, the Signify controller transforms the bran:

this.bran = MtrDex.Salt_128 + 'A' + bran.substring(0, 21)  // qb64 salt for seed
this.salter = new Salter({ qb64: this.bran, tier: this.tier })

This process:

• Prepends the Salt_128 derivation code to the bran
• Creates a qb64-encoded salt for key derivation
• Initializes a Salter primitive for key generation
• Derives the Client AID prefix deterministically

The Salter primitive (one of the six core cesride primitives) represents a seed and has the ability to generate new Signer primitives (private keys). This architecture enables reproducible key generation while maintaining security through the salt's entropy.

ACDC Privacy Protection

In ACDC credentials, the u field provides correlation resistance through salt-based blinding:

{
  "v": "ACDC10JSON00011c_",
  "d": "EAdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
  "u": "0ABghkDaG7OY1wjaDAE0qHcg",
  "i": "did:keri:EBkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
  "s": "ED6jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
  "a": "EEveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY"
}

The u field salt ensures that:

• Identical credentials for different holders produce different SAIDs
• Rainbow table attacks cannot precompute credential hashes
• Selective disclosure can hide attributes without revealing structure
• Private ACDC variants can blind entire attribute sections

Blindable State TEL

The Salty Nonce Blinding Factor mechanism enables selective credential state disclosure. An issuer can blind the state of a credential in a Transaction Event Log such that only parties possessing the salt can verify the credential's current state (issued, revoked, suspended).

This mechanism addresses the privacy requirement: "A credential holder may not want their employment state information shared with former possible employers in future interactions." By controlling salt distribution, the holder controls who can verify credential state, enabling:

• Issuer-controlled blinding of TEL state
• Issuee-requested blinding for privacy protection
• Selective verifier access through salt sharing
• Revocation privacy where only authorized parties see revocation status

Related Primitives

Salter Primitive

The Salter is one of six core cesride cryptographic primitives. It:

• Represents a seed (entropy source)
• Generates Signer primitives (private keys)
• Encapsulates salt functionality in CESR encoding
• Provides deterministic key derivation from salt values

The Salter primitive bridges the gap between human-memorable passphrases (bran) and cryptographically strong key material, using salts as the entropy source that ensures uniqueness and unpredictability.

Bran (Seed/Passphrase)

The bran is KERI's term for a passphrase or seed used as primary input for key generation. The term was specifically chosen to avoid conflicts with existing KERI usage of "seed" and "salt" while maintaining semantic connection to seed-related concepts. Dr. Sam Smith explains: "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."

The relationship between salt and bran:

• Bran provides user-controlled entropy (memorizable passphrase)
• Salt provides system-generated entropy (random value)
• Combined through key derivation functions (Argon2id)
• Produces deterministic yet unpredictable key pairs

Cryptonym

A cryptonym is a cryptographic pseudonymous identifier derived from a random or pseudo-random secret seed or salt via a one-way cryptographic function. The salt serves as the entropy source for cryptonym generation, ensuring:

• Universal uniqueness through high entropy
• Unpredictability through cryptographic derivation
• Controller provability - only the salt holder can prove control
• Self-certification - the identifier is cryptographically bound to its derivation

Cryptonyms exemplify how salts enable KERI's self-certifying identifier architecture, where identifiers are derived from cryptographic material rather than assigned by authorities.

SAID and Digest Primitives

Salts interact with SAID (Self-Addressing Identifier) computation in ACDCs. The u field salt is included in the SAID calculation, ensuring that:

• Different salts produce different SAIDs even for identical content
• SAID verification confirms both content and salt integrity
• Compact disclosure can reference SAIDs without revealing salts
• Full disclosure reveals both content and salt for verification

The Diger primitive (digest representation) verifies that input data hashes to expected values. When salts are included in hashed data, the Diger verification confirms both the data and the salt's contribution to the hash.

Implementation Considerations

Security Best Practices

The vLEI Ecosystem Governance Framework establishes strict requirements for salt management:

Generation: Salts MUST be generated using cryptographically secure random number generators providing approximately 128 bits of entropy. The use of basic PRNGs or predictable values compromises the entire key derivation security model.

Storage: Salts MUST be protected with the same rigor as private keys:

• Encrypted at rest in keystores
• Never transmitted in plaintext over networks
• Backed up securely using approved mechanisms (1Password CLI, macOS Keychain)
• Access controlled independently of controller keys

Lifecycle Management: Salts are typically immutable once generated for a keystore. Changing a salt would change all derived keys, effectively creating a new identity. The governance framework requires 18-month support for previous versions during specification upgrades, implying salt stability across version transitions.

Testing vs Production

The documentation repeatedly emphasizes the distinction between testing and production salt usage:

Testing Environments:

• May use predetermined salts for reproducible tests
• Well-known witnesses with predictable salts enable test automation
• Configuration files may contain salts with --insecure flag
• Salt values may be hardcoded in test scripts

Production Environments:

• MUST use cryptographically random salts
• MUST NOT use well-known witness configurations
• MUST NOT store salts in plaintext configuration files
• MUST implement secure backup and recovery procedures

The governance framework explicitly warns: "For testing purposes, never put a salt in a file like this" when showing example configurations with exposed salt values.

Multi-Signature Considerations

In multi-signature group AIDs, each participant generates their own salt for their individual keystore. The group AID's security depends on:

• Independent salt generation by each participant
• No salt sharing between group members
• Individual key derivation from separate salts
• Threshold signature schemes that don't require salt coordination

This architecture ensures that compromise of one participant's salt doesn't compromise the entire group's security, maintaining the threshold structure security model where multiple independent attack surfaces must be overcome.

Quantum Resistance

While salts themselves are not quantum-vulnerable (they're random data, not algorithmic constructs), their role in key derivation affects post-quantum security:

• 128-bit salts provide adequate entropy for post-quantum key derivation
• Argon2id remains secure against quantum attacks (it's a classical algorithm)
• Derived key algorithms (Ed25519, X25519) may require quantum-safe alternatives
• Salt reuse with quantum-safe algorithms maintains backward compatibility

KERI's pre-rotation mechanism provides post-quantum security for identifier control even if current signing algorithms are compromised, and salts play a role in deriving the pre-rotated keys that enable this protection.

Blindable State TEL: Implement Salty Nonce Blinding Factor using one of three approaches:

1. HTOP (RFC 6238) for HMAC-based secret sharing
2. TOTP (RFC 6238) for time-synchronized access control
3. HDKM for hierarchical deterministic key management

The issuer performs blinding, but the issuee can request blinding for privacy protection. Only parties possessing the salt can verify credential state.

Testing vs Production

Development Environments:

• May use predetermined salts for reproducible tests
• Well-known witnesses with predictable salts enable test automation
• Configuration files may contain salts with --insecure flag
• Example: --salt 0AAkG1BmB7xnXBxo2Aasxrq9 in test scripts

Production Deployments:

• MUST use cryptographically random salts from CSPRNGs
• MUST NOT use well-known witness configurations
• MUST NOT store salts in plaintext configuration files
• MUST implement secure backup and recovery procedures
• Custom witness salts MUST be changed from default values when using templates

Multi-Signature Considerations

In group multi-sig AIDs:

• Each participant generates their own salt independently
• No salt sharing between group members
• Individual key derivation from separate salts
• Threshold signatures don't require salt coordination
• Compromise of one participant's salt doesn't compromise group security

CESR Encoding

Salts are encoded as CESR primitives with:

• Derivation code prefix (typically 0A for 128-bit random salt)
• Base64 URL-safe encoding for text domain
• Raw binary encoding for compact transmission
• Self-framing properties for stream parsing

The Salter primitive encapsulates this encoding and provides methods for key generation.

Version Management

Per vLEI governance framework:

• Previous specification versions must be supported for 18 months
• New versions must be implemented within 12 months
• Breaking changes must not be used until adoption period expires
• Salt formats and derivation algorithms must maintain backward compatibility during transitions

Quantum Considerations

• 128-bit salts provide adequate entropy for post-quantum key derivation
• Argon2id remains secure against quantum attacks
• Derived key algorithms (Ed25519, X25519) may require quantum-safe alternatives in future
• Salt reuse with quantum-safe algorithms maintains backward compatibility
• KERI's pre-rotation mechanism provides post-quantum security for identifier control