Entropy Requirements

The salty nonce blinding factor must provide cryptographic-strength entropy of at least 128 bits to ensure resistance against brute-force attacks and rainbow table pre-computation. This entropy requirement aligns with modern cryptographic standards for secret values and ensures that the blinding factor cannot be feasibly guessed or derived through exhaustive search.

The high entropy serves two critical security functions:

1. Rainbow Table Resistance: By adding sufficient randomness to the TEL state hash inputs, the blinding factor makes pre-computation attacks infeasible. Without the blinding factor, an attacker could pre-compute hashes of all possible credential states and use these tables to determine state by observing published hash values.

2. Correlation Prevention: The entropy ensures that different credentials, even from the same issuer, cannot be correlated through their blinded state values unless the verifier possesses the specific blinding factor for each credential.

Cryptographic Derivation Methods

The specification identifies three standardized approaches for deriving and sharing the salty nonce blinding factor:

1. HOTP (HMAC-Based One-Time Password)

Referenced per RFC 6238, HOTP provides a counter-based derivation mechanism where:

• A shared secret key is established between issuer and authorized parties
• The blinding factor is derived using HMAC (Hash-based Message Authentication Code) with a counter value
• Each credential or state transition can use a different counter value
• The deterministic derivation allows both parties to independently compute the same blinding factor

This approach is particularly suitable for scenarios where the issuer and holder maintain synchronized counter state, enabling predictable blinding factor generation without requiring transmission of the factor itself for each credential.

2. TOTP (Time-Based One-Time Password)

Also specified in RFC 6238, TOTP extends the HOTP concept with time-based synchronization:

• The blinding factor is derived using HMAC with a time-based counter
• Time windows (typically 30-second intervals) replace explicit counter values
• Both parties use synchronized clocks to derive the same blinding factor
• Temporal binding provides additional security properties for time-sensitive credentials

TOTP is advantageous in scenarios where maintaining explicit counter synchronization is impractical, as it leverages the natural synchronization of system clocks. However, it requires consideration of clock drift and time window tolerances.

3. HDKM (Hierarchical Deterministic Key Management)

Based on hierarchical deterministic key derivation (similar to BIP-32 for cryptocurrency wallets), HDKM provides:

• A shared master key from which subkeys are deterministically derived
• Hierarchical structure enabling organized key management
• Predictable derivation of multiple blinding factors from a single master secret
• Support for key delegation and hierarchical authorization structures

HDKM is particularly powerful for complex credential ecosystems where:

• Multiple credentials share a common root of trust
• Hierarchical delegation of blinding authority is required
• Organized key management across credential families is beneficial

The deterministic derivation ensures that both issuer and authorized verifiers can independently compute the same blinding factors for a hierarchy of credentials without requiring transmission of each individual factor.

Data Format & Encoding

Integration with UUID Field

In ACDC structures, the salty nonce blinding factor is typically incorporated through the u (UUID) field at the top level of the ACDC field map. This field serves as a high-entropy pseudorandom string that:

• Must be at least 128 bits (16 bytes) in length
• Is represented as a qualified CESR primitive
• Participates in the SAID computation for the ACDC
• Transforms a "public ACDC" into a "private ACDC"

The presence of the u field fundamentally changes the privacy characteristics of the ACDC:

Public ACDC (no u field):

• SAID is deterministically computable from schema and attributes
• Vulnerable to rainbow table attacks if schema and possible attribute values are known
• Suitable only for truly public, non-confidential data

Private ACDC (with u field):

• SAID incorporates high-entropy blinding factor
• Rainbow table attacks become computationally infeasible
• Enables privacy-preserving credential architectures

CESR Encoding

The salty nonce blinding factor, when represented as the UUID field value, follows CESR encoding conventions:

• Encoded as a qualified cryptographic primitive
• Includes a derivation code prefix indicating the primitive type
• Supports both text domain (Base64 URL-safe) and binary domain representations
• Maintains composability with other CESR primitives in event streams

The CESR encoding ensures that the blinding factor can be efficiently serialized, transmitted, and parsed within KERI event streams while maintaining the dual text-binary composability properties that enable CESR's universal applicability.

TEL State Blinding

When applied to TEL state information, the blinding factor is incorporated into the cryptographic hash computation that represents the credential state:

blinded_state_hash = Hash(credential_state || salty_nonce_blinding_factor)

This construction ensures that:

• The published hash reveals no information about the actual credential state
• Only parties possessing the blinding factor can verify the state
• The hash serves as a cryptographic commitment to both state and blinding factor
• State changes require new blinding factors to maintain privacy

Usage in KERI/ACDC

Blindable State TEL Architecture

The salty nonce blinding factor is the foundational privacy mechanism for Blindable State TELs, a specialized form of Transaction Event Log that enables selective disclosure of credential state. The architecture operates as follows:

Issuance Phase

1. Credential Creation: The issuer creates an ACDC credential with a high-entropy u field containing the salty nonce blinding factor

2. TEL Initialization: A corresponding TEL is created to track the credential's lifecycle state (issued, revoked, suspended)

3. State Blinding: The TEL state is cryptographically blinded using the salty nonce, making the state unobservable to parties without the blinding factor

4. Secret Sharing: The blinding factor is shared with the issuee (credential holder) through one of the three derivation methods (HOTP, TOTP, or HDKM)

Presentation Phase

1. Selective Disclosure: When presenting the credential, the holder decides whether to disclose the blinding factor to the verifier

2. State Verification: If the blinding factor is disclosed, the verifier can:

   • Compute the expected blinded state hash
   • Compare against the published TEL state
   • Verify that the credential state matches the claimed status

3. Privacy Preservation: If the blinding factor is not disclosed, the verifier cannot determine the credential state, protecting the holder's privacy

Operational Control Model

The specification establishes clear roles for blinding operations:

Issuer Responsibilities:

• Performs the actual blinding operation on TEL state
• Generates or derives the salty nonce blinding factor
• Publishes blinded state to the TEL
• Manages the cryptographic infrastructure for state updates

Issuee Rights:

• Can request that blinding be applied to their credentials
• Controls disclosure of the blinding factor during presentations
• Determines which verifiers receive state visibility
• Maintains custody of the shared secret

This operational model provides the credential holder with meaningful privacy control while maintaining the issuer's authority over the credential lifecycle and state management.

Use Case: Employment Credential Privacy

The specification provides a concrete example illustrating the privacy value of salty nonce blinding:

Scenario: An individual holds employment credentials issued by their current employer. They do not want former employers or potential future employers to be able to verify the current state of these credentials without explicit consent.

Without Blinding: Any party with access to the public TEL could observe:

• Whether the employment credential is currently active
• When it was issued
• Whether it has been revoked
• State transition history

This ambient observability enables unwanted surveillance and correlation.

With Blinding:

• The TEL state is cryptographically hidden
• Former employers cannot determine current employment status
• The credential holder selectively discloses state only to authorized verifiers
• Privacy is maintained while preserving verifiability for legitimate use cases

This example demonstrates how salty nonce blinding factors enable need-to-know, just-in-time disclosure of credential state, aligning with privacy-by-design principles.

Grace Period: Ghost Credentials

An important operational consideration is the grace period for revocation processing. When a credential is revoked:

1. The revocation event is created and signed by the issuer
2. A grace period (typically 90 days) exists before the revocation is finalized in the registry
3. During this period, the credential exists in a "ghost" state
4. The blinding factor continues to protect the credential's state during this transition

This grace period mechanism, combined with state blinding, provides:

• Time for revocation disputes or corrections
• Continued privacy protection during state transitions
• Operational flexibility for credential lifecycle management

Related Primitives

UUID Field in ACDCs

The salty nonce blinding factor is most commonly manifested as the u (UUID) field in ACDC structures. This field:

• Serves as the container for the high-entropy blinding value
• Participates in SAID computation
• Distinguishes private ACDCs from public ACDCs
• Enables graduated disclosure mechanisms

The UUID field represents the practical implementation of the abstract blinding factor concept within the ACDC data structure.

SAID Protocol Integration

The blinding factor fundamentally interacts with the SAID (Self-Addressing Identifier) protocol:

• The SAID is computed over the entire ACDC, including the u field
• The high entropy of the blinding factor makes the SAID unpredictable
• This unpredictability prevents rainbow table attacks on the SAID itself
• The SAID serves as both identifier and integrity proof for the blinded structure

This integration ensures that the privacy properties of the blinding factor extend to the identifier itself, preventing correlation through SAID observation.

Relationship to Selective Disclosure

The salty nonce blinding factor is a foundational primitive for selective disclosure mechanisms in ACDCs:

• Compact Disclosure: Discloses only SAIDs of field maps, with blinding protecting undisclosed content
• Partial Disclosure: Reveals some fields while keeping others blinded
• Graduated Disclosure: Progressive revelation of information as trust is established

The blinding factor enables these disclosure patterns by ensuring that undisclosed information remains cryptographically protected even when partial information is revealed.

Implementation Considerations

Entropy Source Requirements

Implementations must ensure that the salty nonce blinding factor is generated from a cryptographically secure pseudorandom number generator (CSPRNG). Weak entropy sources can completely undermine the privacy properties:

• Use operating system-provided CSPRNGs (e.g., /dev/urandom, CryptGenRandom, getrandom())
• Avoid user-space PRNGs without cryptographic strength
• Ensure sufficient entropy pool initialization before generation
• Consider hardware random number generators for high-security applications

Secret Sharing Security

The three derivation methods (HOTP, TOTP, HDKM) require secure establishment of shared secrets:

Initial Secret Exchange:

• Use authenticated, encrypted channels for master secret transmission
• Consider out-of-band verification of shared secrets
• Implement key confirmation protocols to verify successful sharing
• Protect master secrets with hardware security modules (HSMs) or trusted execution environments (TEEs) when possible

Operational Security:

• Rotate master secrets periodically
• Implement secure deletion of expired blinding factors
• Audit access to blinding factor storage
• Consider multi-party computation for sensitive blinding operations

Performance Implications

Blinding operations introduce computational overhead:

• Hash computation for blinded state requires additional processing
• Derivation of blinding factors (especially HDKM) may be computationally intensive
• Storage requirements increase with blinding factor management
• Network transmission includes additional cryptographic material

Implementations should:

• Cache derived blinding factors when appropriate
• Use efficient cryptographic libraries
• Consider hardware acceleration for high-throughput scenarios
• Balance security requirements against performance constraints

Interoperability Considerations

For ecosystem-wide adoption, implementations must ensure:

• Consistent interpretation of RFC 6238 parameters (time windows, counter ranges)
• Standardized HDKM derivation paths and algorithms
• Compatible CESR encoding of blinding factors
• Agreed-upon minimum entropy requirements
• Standardized error handling for blinding factor mismatches

The ACDC specification provides the normative framework, but implementation details require careful coordination across the ecosystem to ensure interoperability.

Operational Considerations

• Implement grace periods for revocation processing (typically 90 days)
• Support "ghost credential" states during grace periods
• Enable credential holders to request blinding
• Provide clear APIs for blinding factor disclosure control

Performance Optimization

• Cache derived blinding factors when appropriate
• Use efficient cryptographic libraries
• Consider hardware acceleration for high-throughput scenarios
• Balance security requirements against performance constraints

Interoperability

• Follow RFC 6238 standards for HOTP/TOTP parameters
• Standardize HDKM derivation paths and algorithms
• Ensure compatible CESR encoding across implementations
• Implement standardized error handling for blinding factor mismatches
• Coordinate implementation details across the ecosystem