Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 12 GitHub source documents. All source documents are searchable here.
Last updated: October 7, 2025
This content is meant to be consumed by AI agents via MCP. Click here to get the MCP configuration.
Note: In rare cases it may contain LLM hallucinations.
For authoritative documentation, please consult the official GLEIF vLEI trainings and the ToIP Glossary.
A cryptographic commitment to content achieved by digitally signing a digest (cryptographic hash) of that content, providing both content integrity verification and authentication of the .
A signed digest is a fundamental cryptographic primitive in KERI that represents a commitment to content through the combination of two core cryptographic operations:
This primitive serves as a building block for establishing authenticity, integrity, and non-repudiable commitments throughout the KERI protocol stack, including Key Event Logs (KEL), Authentic Chained Data Containers (ACDC), and cryptographic seals.
Signed digests enable controllers to make verifiable commitments to data without requiring the full content to be transmitted, stored, or verified in every context. This provides:
Signed digests are classified as cryptographic commitment primitives within KERI's architecture. They represent a specific pattern of combining:
This combination creates what KERI documentation refers to as "trust who said it not what was said" - establishing consistent attribution as the foundation for trust.
Signed digests in KERI leverage multiple cryptographic algorithm families:
KERI supports various cryptographic hash functions through its derivation code system in CESR:
All hash functions used must be collision-resistant, meaning it is computationally infeasible to find two different inputs that produce the same digest.
KERI's signed digests support multiple signature algorithms:
The KERI whitepaper emphasizes that the protocol is designed to be cryptographically agile, allowing migration to new algorithms as cryptographic research advances or quantum computing threats materialize.
Signed digests provide multiple security guarantees:
The digest component ensures cryptographic integrity through collision resistance. For a hash function H and content C:
D = H(C) produces a fixed-size digestC' ≠ C produces D' = H(C') where D' ≠ D (with overwhelming probability)C' such that H(C') = H(C) (collision resistance)This property is fundamental to KERI's append-only event logs, where each event includes a digest of the previous event, creating an immutable chain.
The signature component provides cryptographic authentication:
In KERI's context, this enables end-verifiable statements where validators can cryptographically verify that a specific AID controller made a commitment without trusting intermediaries.
KERI's pre-rotation mechanism leverages signed digests of future keys. As documented in the KERI whitepaper:
Typical sizes for signed digest components:
A complete signed digest primitive consists of:
Total size typically ranges from 97 to 182 bytes depending on algorithm choices.
Signed digests in KERI are encoded using CESR (Composable Event Streaming Representation), which provides dual text-binary encoding with composability properties.
CESR represents cryptographic primitives as qualified primitives that include:
This creates self-framing primitives where parsers can determine type and length without external context.
CESR uses specific derivation codes for different hash algorithms:
E: SHA-256 digest (32 bytes)F: SHA-512 digest (64 bytes)G: SHA3-256 digest (32 bytes)H: SHA3-512 digest (64 bytes)I: BLAKE3-256 digest (32 bytes)0D: BLAKE2b-256 digest (32 bytes)0E: BLAKE2s-256 digest (32 bytes)Signatures use different code families:
B: Ed25519 signature (64 bytes)0B: ECDSA secp256k1 signature (64 bytes)C: Ed448 signature (114 bytes)For indexed signatures (used in multi-sig scenarios), additional codes indicate the signing key index.
CESR provides text-binary concatenation composability, meaning primitives can be converted between domains without loss:
In the text domain, signed digests are encoded as Base64 URL-safe strings:
EABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_
Example SHA-256 digest in text domain:
EL1L56LyoKrIofnn0oPChS4EyzMHEEk75INJohDS_-DT
Where:
E = SHA-256 derivation codeIn the binary domain, the same primitive is encoded as raw bytes:
The binary encoding is more compact and efficient for storage and transmission.
CESR's composability means:
This enables pipelining and streaming of cryptographic operations at scale.
The KERI whitepaper emphasizes that derivation codes serve multiple purposes:
This design supports KERI's goal of minimally sufficient means - providing just enough information for verification without unnecessary overhead.
Signed digests are fundamental to KEL structure:
Each key event includes a signed digest of the previous event, creating a backward-chained log:
This chaining makes the KEL tamper-evident - any modification breaks the digest chain.
Establishment events include signed digests of next key commitments:
next field contains digests of pre-rotated public keysAs the KERI whitepaper explains, this provides forward security and post-quantum protection.
Every key event is signed by the current authoritative keys:
Validators verify these signed digests to confirm event authenticity.
ACDCs extensively use signed digests for verifiable credentials:
ACDCs use SAIDs - self-addressing identifiers that are digests of the ACDC content:
d field for its SAIDd field set to a dummy value)ACDCs support compact disclosure using signed digests:
ACDCs form directed acyclic graphs (DAGs) through signed digest references:
Seals are signed digest commitments that anchor external data to KELs:
Interaction events can include seals that commit to:
The seal contains a signed digest, creating a cryptographic anchor from the KEL to external data.
The TEL system uses signed digests to anchor credential state to KELs:
next commitmentsThe KERI whitepaper emphasizes end-verifiable validation:
This process ensures the entire KEL is internally consistent and cryptographically verifiable.
Signed digests build upon basic digest primitives:
Signed digests incorporate signature primitives:
SAIDs are specialized signed digests:
Seals are signed digest commitments in KELs:
Pre-rotation uses signed digests of future keys:
Before computing digests, content must be canonicalized:
Failure to canonicalize identically will produce different digests, breaking verification.
KERI uses attached signatures rather than embedded:
For multi-sig AIDs:
Signed digest operations have performance implications:
The KERI whitepaper emphasizes:
Different implementations may canonicalize differently, causing verification failures. Solution: Use standardized serialization libraries and test cross-implementation compatibility.
Some signature schemes allow multiple valid signatures for the same message. Solution: Use non-malleable schemes (Ed25519) or canonical signature encoding.
Signature verification timing can leak information. Solution: Use constant-time comparison operations for cryptographic values.
Verifying signatures with wrong key state (e.g., rotated keys). Solution: Always validate key state at the specific KEL sequence number being verified.
Signed digests integrate with broader KERI components:
Proper implementation requires understanding these interactions and maintaining consistency across the entire KERI stack.
Before computing any digest, content MUST be canonicalized to ensure consistent hash values across implementations:
Testing: Cross-validate digest computation with reference implementations (KERIpy, KERIox) to ensure canonicalization compatibility.
KERI uses attached signatures rather than embedded signatures:
This pattern keeps message bodies clean and enables efficient signature verification without parsing embedded signatures.
For multi-sig AIDs, implement proper threshold validation:
Critical: Always validate that signing keys are authoritative at the specific KEL sequence number being verified.
When verifying signed digests in KEL events:
Never verify signatures using current key state when validating historical events.
Use constant-time comparison for all cryptographic values to prevent timing attacks:
# BAD - timing attack vulnerable
if computed_digest == expected_digest:
return True
# GOOD - constant-time comparison
import hmac
if hmac.compare_digest(computed_digest, expected_digest):
return True
For key generation and signing:
/dev/urandom or getrandom() syscallrand(), random(), or predictable seedsDesign implementations to support algorithm migration:
Some ECDSA implementations allow signature malleability (multiple valid signatures for same message). Solution: Use Ed25519 (non-malleable) or enforce canonical ECDSA encoding.
JavaScript objects and Python dicts may not preserve insertion order in older versions. Solution: Use ordered dictionaries or explicit field ordering during serialization.
CESR uses Base64 URL-safe encoding without padding characters. Solution: Ensure Base64 encoding/decoding strips = padding and uses URL-safe alphabet (-_ instead of +/).
Mixing digest algorithms between commitment and verification. Solution: Always extract and respect derivation codes; never assume algorithm.
Implementations should include:
Consult these authoritative implementations:
When in doubt about specification interpretation, defer to KERIpy behavior as the reference standard.