A high-entropy cryptographic value (≥128 bits) used in KERI's Blindable State TELs to hide credential state information from unauthorized verifiers while maintaining verifiability for authorized parties who possess the shared secret.
Related Concepts
No related concepts available
Comprehensive Explanation
salty-nonce-blinding-factor
Technical Definition
The salty-nonce-blinding-factor is a cryptographic privacy primitive within KERI's Transaction Event Log (TEL) infrastructure that enables selective hiding of credential state information. It functions as a high-entropy pseudorandom value (minimum 128 bits) that, when incorporated into cryptographic hash computations of TEL state, renders that state unobservable to parties who do not possess the blinding secret.
Formally, the salty nonce blinding factor serves as a shared secret between the credential issuer and authorized verifiers, enabling the issuer to cryptographically blind the revocation/issuance state of credentials in a way that:
Maintains cryptographic verifiability for parties possessing the blinding factor
Enables selective disclosure of credential state based on holder privacy preferences
Creates controlled correlation only between issuer and issuee
This mechanism is formally specified within the ACDC specification's Blindable State TEL section and represents a critical privacy-enhancing component for verifiable credential architectures where credential holders require granular control over who can verify their credential status.
Cryptographic Properties
Implementation Notes
Critical Implementation Requirements
Entropy Generation
MUST use cryptographically secure pseudorandom number generators (CSPRNGs) for blinding factor generation
MUST ensure minimum 128-bit entropy for all blinding factors
SHOULD use operating system-provided entropy sources (/dev/urandom, CryptGenRandom, getrandom())
SHOULD consider hardware RNGs for high-security applications
Derivation Method Selection
HOTP (RFC 6238):
Suitable for scenarios with synchronized counter state
Requires secure counter management and synchronization
Deterministic derivation enables independent computation by both parties
TOTP (RFC 6238):
Suitable when counter synchronization is impractical
Requires consideration of clock drift and time window tolerances
Typically uses 30-second time windows
HDKM (Hierarchical Deterministic Key Management):
Suitable for complex credential ecosystems with hierarchical structures
Enables organized key management across credential families
Supports key delegation and hierarchical authorization
Secret Sharing Security
MUST use authenticated, encrypted channels for master secret transmission
SHOULD implement out-of-band verification of shared secrets
SHOULD implement key confirmation protocols
SHOULD protect master secrets with HSMs or TEEs when possible
MUST implement secure deletion of expired blinding factors
ACDC Integration
Incorporate blinding factor in the u (UUID) field of ACDCs
Ensure the u field participates in SAID computation
Encode blinding factor as qualified CESR primitive
Maintain minimum 128-bit length for UUID field
TEL State Blinding
Compute blinded state as: Hash(credential_state || salty_nonce_blinding_factor)
Publish only the blinded hash to the TEL
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:
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.
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.
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:
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:
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
Credential Creation: The issuer creates an ACDC credential with a high-entropy u field containing the salty nonce blinding factor
TEL Initialization: A corresponding TEL is created to track the credential's lifecycle state (issued, revoked, suspended)
State Blinding: The TEL state is cryptographically blinded using the salty nonce, making the state unobservable to parties without the blinding factor
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
Selective Disclosure: When presenting the credential, the holder decides whether to disclose the blinding factor to the verifier
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
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:
The revocation event is created and signed by the issuer
A grace period (typically 90 days) exists before the revocation is finalized in the registry
During this period, the credential exists in a "ghost" state
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
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
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.
Implement secure storage for blinding factors
Support selective disclosure during credential presentation
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