• Blake3-256: A modern, high-performance cryptographic hash function producing 256-bit digests
• Blake2b-256: An earlier Blake variant with 256-bit output
• SHA-256: The widely-deployed SHA-2 family hash producing 256-bit digests
• SHA3-256: The Keccak-based SHA-3 standard with 256-bit output

The choice of hash algorithm affects both security properties and performance characteristics. Blake3, for example, offers superior performance while maintaining strong security guarantees, making it a preferred choice in many KERI implementations.

Security Properties

Digers inherit the security properties of their underlying hash algorithms:

• Collision Resistance: Computationally infeasible to find two different inputs that produce the same digest
• Pre-image Resistance: Given a digest, computationally infeasible to find any input that produces it
• Second Pre-image Resistance: Given an input and its digest, computationally infeasible to find a different input with the same digest
• Avalanche Effect: Small changes in input produce dramatically different digests

These properties enable digests to serve as cryptographic commitments - once a diger is created from some data, the data cannot be changed without detection, and the digest uniquely identifies that specific data.

Output Sizes

Most hash algorithms used in KERI produce 256-bit (32-byte) digests, providing approximately 128 bits of collision resistance security. This security level is considered sufficient for long-term cryptographic applications and aligns with post-quantum security recommendations.

Data Format & Encoding

CESR Encoding Structure

Digers follow CESR's qualified primitive encoding pattern, consisting of:

1. Derivation Code: A prefix indicating the hash algorithm and encoding format
2. Digest Value: The actual hash output, encoded in Base64 or binary

The derivation code enables self-describing primitives - a parser can determine the hash algorithm and digest length by examining only the first few characters/bytes.

Text Domain Representation

In CESR's text domain, digers are encoded as Base64 URL-safe strings with prepended derivation codes. For example, a Blake3-256 digest might appear as:

EABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv

Where:

• E is the derivation code indicating Blake3-256
• The remaining characters are the Base64-encoded 32-byte digest

The text representation is human-readable, can be safely transmitted in JSON/text protocols, and maintains CESR's composability property when concatenated with other primitives.

Binary Domain Representation

In CESR's binary domain, digers use compact binary derivation codes followed by raw digest bytes. The binary encoding is more efficient for storage and transmission while maintaining the same semantic content as the text representation.

CESR's composability guarantee ensures that digests can be converted between text and binary domains without loss of information or boundary ambiguity when concatenated with other primitives.

Standard Method Interface

All diger implementations provide a standard method interface inherited from the cesride primitive specification:

• .qb64(): Returns the qualified Base64 text representation as a string
• .qb64b(): Returns the qualified Base64 representation as bytes
• .qb2(): Returns the qualified binary representation
• .code(): Returns the derivation code indicating the hash algorithm
• .raw(): Returns the unqualified raw digest bytes

This uniform interface enables consistent handling of digests across different KERI implementations and programming languages.

Usage in KERI/ACDC

Self-Addressing Identifiers (SAIDs)

The primary use of digers in KERI is for creating Self-Addressing Identifiers (SAIDs). A SAID is a special type of identifier where the identifier itself is the digest of the data it identifies. This creates a cryptographically verifiable binding between identifier and content.

SAIDs are used extensively throughout KERI:

• Event SAIDs: Each key event in a KEL has a SAID that uniquely identifies and commits to that event's content
• ACDC SAIDs: Authentic Chained Data Containers (ACDCs) use SAIDs to create verifiable credential identifiers
• Schema SAIDs: Credential schemas are identified by SAIDs of their schema definitions

The SAID mechanism enables content-addressable data structures where the identifier proves the integrity of the identified content.

Key Event Commitment

In KELs, digests serve multiple commitment functions:

• Event Chaining: Each event includes a digest of the prior event, creating a hash-chained log structure
• Next Key Commitment: Pre-rotation uses digests of next keys (called "ndigers") to commit to future rotation keys before they're exposed
• Seal Anchoring: Seals use digests to anchor external data to specific key events

These digest-based commitments create the cryptographic backbone of KERI's security model, enabling detection of unauthorized modifications and ensuring event ordering.

ACDC Compact Disclosure

In ACDCs, digests enable compact disclosure mechanisms:

• Attribute Blinding: Undisclosed attributes are replaced with their digests
• Selective Disclosure: Recipients receive digests of undisclosed fields, which can be verified when full disclosure occurs later
• Partial Disclosure: Field maps can be compacted to their SAIDs for privacy-preserving presentations

This digest-based disclosure pattern allows graduated revelation of credential information while maintaining cryptographic verifiability at each stage.

Verification Procedures

Verifying a diger involves:

1. Extract the derivation code to determine the hash algorithm
2. Hash the input data using the indicated algorithm
3. Compare the computed digest with the diger's stored value
4. Confirm equality - if digests match, the input is verified

This verification process is deterministic and requires no trusted third parties - anyone with the input data and the diger can independently verify the commitment.

Related Primitives

Verfer (Public Key Primitive)

While digests and public keys serve different cryptographic functions, both are CESR primitives with similar encoding patterns. Verfers represent public keys and enable signature verification, whereas digests enable content commitment. In KERI, verfers are often digested to create compact key commitments in pre-rotation mechanisms.

Signer (Private Key Primitive)

Signers represent private keys and create signatures. The relationship between digests and signatures is complementary - digests commit to data content, while signatures prove authorship. In practice, signatures are often computed over digests rather than raw data for efficiency.

Salter (Seed Primitive)

Salters represent cryptographic seeds used to derive key material. Seeds are often protected by storing only their digests in certain contexts, creating a commitment to the seed without exposing it. The salter-diger relationship enables deterministic key derivation with privacy preservation.

Composition Patterns

Digers frequently appear in composed structures:

• Digest Lists: Arrays of digests for multi-element commitments (e.g., witness lists, next key sets)
• Merkle Trees: Hierarchical digest structures for efficient proof-of-inclusion
• Seal Structures: Digests combined with event sequence numbers for anchoring

CESR's composability property ensures these structures can be efficiently encoded and parsed in both text and binary domains.

Implementation Considerations

Hash Algorithm Selection

Implementers must choose appropriate hash algorithms based on:

• Security Requirements: 256-bit digests provide ~128-bit security, sufficient for most applications
• Performance Needs: Blake3 offers superior performance for high-throughput scenarios
• Compatibility: SHA-256 provides maximum interoperability with existing systems
• Post-Quantum Resistance: All common hash algorithms are considered post-quantum secure

Digest Caching

For frequently-accessed data, implementations should cache computed digests rather than recomputing them. This is particularly important for:

• Event SAIDs in KEL processing
• ACDC credential identifiers
• Schema identifiers

Caching strategies must ensure cache invalidation when underlying data changes.

Streaming Hash Computation

For large data objects, implementations should use streaming hash APIs that process data incrementally rather than loading entire objects into memory. This is critical for:

• Large credential attachments
• Bulk event processing
• Archive verification

Error Handling

Digest verification failures indicate either:

• Data corruption: Transmission or storage errors
• Malicious modification: Intentional tampering
• Implementation bugs: Incorrect hash computation

Implementations must treat verification failures as security-critical events and handle them appropriately (typically by rejecting the data and logging the failure).

Derivation Code Management

Implementations must maintain accurate mappings between derivation codes and hash algorithms. The CESR specification defines standard codes, but implementations should validate codes before processing and reject unknown codes to prevent security vulnerabilities.

Security Considerations

Collision Attacks

While modern hash algorithms are collision-resistant, implementations should:

• Use 256-bit or larger digests
• Monitor cryptographic research for algorithm weaknesses
• Support algorithm agility to enable migration if vulnerabilities emerge

Length Extension Attacks

Some hash algorithms (notably SHA-256) are vulnerable to length extension attacks. KERI's use of digests in fixed-structure events mitigates this risk, but implementations should be aware of the issue when using digests in novel contexts.

Timing Attacks

Digest comparison operations should use constant-time comparison functions to prevent timing side-channels that could leak information about digest values.

Performance Optimization

Hardware Acceleration

Modern CPUs provide hardware acceleration for common hash algorithms (e.g., SHA-256 via SHA extensions). Implementations should leverage these features when available for optimal performance.

Parallel Processing

Blake3 supports parallel hashing through its tree-based construction. Implementations processing large data sets should exploit this parallelism for maximum throughput.

Batch Verification

When verifying multiple digests, implementations can optimize by:

• Batching hash computations
• Using SIMD instructions for parallel processing
• Pipelining verification operations

These optimizations are particularly valuable in witness and watcher implementations processing high-volume event streams.

Integration with KERI Components

• KEL Processing: Digests chain events and commit to next keys
• ACDC Handling: Digests enable compact/selective disclosure
• SAID Generation: Digests create content-addressable identifiers
• Seal Anchoring: Digests commit external data to events

Implementations must correctly handle digests in all these contexts to maintain KERI security properties.