Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 49 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.
An indexed signature (also called 'siger') is a CESR-encoded cryptographic signature attachment that includes an index value indicating which specific public key from a multi-key autonomic identifier's key set was used to generate the signature, enabling deterministic verification in multi-signature schemes.
An indexed signature (canonically termed siger in CESR implementations) is a CESR primitive that represents a cryptographic signature with an embedded index value. The index identifies which specific public key from an ordered set of multiple keys was used to create the signature. This primitive is essential for multi-signature schemes in KERI where a single autonomic identifier (AID) is controlled by multiple key pairs.
Formally, an indexed signature is a self-framing cryptographic primitive that encodes:
The indexed signature solves a fundamental challenge in multi-key systems: signature attribution. Without the index, verifiers would need to attempt verification against all possible public keys, which is computationally inefficient and ambiguous. The indexed approach provides deterministic, efficient signature verification while maintaining the flexibility of multi-key control structures.
Implementations MUST validate that signature indices are within bounds of the current key list before attempting verification. Out-of-bounds indices indicate malformed signatures or incorrect key state retrieval.
After verifying all indexed signatures, implementations MUST confirm that the count of valid signatures meets or exceeds the threshold specified in the event's key state. Insufficient signatures render the event unauthorized.
Implementations SHOULD detect and reject duplicate indices in the signature set, as this may indicate implementation bugs, replay attacks, or malicious manipulation.
Indexed signatures must be parsed according to CESR specifications:
For advanced multi-sig schemes with fractional weights, implementations must:
During partial rotation, implementations must verify that indices correspond to exposed next keys and that unexposed keys remain committed via their digests.
For high-throughput scenarios:
Indexed signatures in KERI primarily use Ed25519 digital signatures, which provide:
The Ed25519 algorithm operates on the Curve25519 elliptic curve and uses:
Indexed signatures inherit the security properties of their underlying signature algorithm:
Non-repudiation: Only the holder of the private key at the specified index could have created the signature, providing cryptographic proof of authorship.
Integrity protection: Any modification to the signed data invalidates the signature, ensuring tamper-evidence.
Index binding: The index is cryptographically bound to the signature through the CESR encoding structure, preventing index substitution attacks.
Threshold compatibility: Multiple indexed signatures can be combined to satisfy threshold signature schemes, where M-of-N signatures are required for authorization.
For Ed25519-based indexed signatures:
Indexed signatures follow CESR's self-framing design with a specific encoding pattern:
[derivation_code][index][signature_bytes]
The derivation code is a 1-2 character prefix that encodes:
In the text domain, indexed signatures use Base64 URL-safe encoding:
Example structure: 0AABxxx...xxx
0A: Derivation code indicating Ed25519 signature with small indexAB: Index value encoded in Base64 (index 0 in this example)xxx...xxx: 64-byte signature encoded as 88 Base64 charactersThe complete primitive is exactly 92 characters (4 + 88), maintaining CESR's requirement that all primitives be integer multiples of 4 characters for composability.
In the binary domain, the same indexed signature is encoded as raw bytes:
CESR defines multiple derivation codes for indexed signatures:
Small index codes (index 0-63):
0A: Ed25519 signature, index encoded in next character0B: ECDSA secp256k1 signature, small indexLarge index codes (index 64+):
2A: Ed25519 signature, index encoded in next 2 characters2B: ECDSA secp256k1 signature, large indexThe choice of code depends on the maximum index value needed for the multi-signature scheme.
Indexed signatures are fundamental to multi-sig AIDs where control authority requires threshold-based signatures from multiple key pairs. When a controller creates a multi-sig AID, they specify:
k field): Ordered list of public keyskt field): Number of signatures required (e.g., "2" for 2-of-3)n field): Ordered list of pre-rotated key digestsnt field): Threshold for next rotationWhen signing a key event, each participating key holder creates an indexed signature where the index corresponds to their position in the current key list.
Inception events and rotation events require indexed signatures from threshold-satisfying subsets of current keys:
{
"v": "KERI10JSON000160_",
"t": "icp",
"d": "EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
"i": "EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
"s": "0",
"kt": "2",
"k": [
"DKxy2sgzfplyr-tgwIxS19f2OchFHtLwPWD3v4oYimBx",
"D8KY1sKmgyjAiUDdUBPNPyrSz_ad_Qf9yzhDNZlEKiMc",
"DEe5T5YEZLccvO_JJpvm2Fz-B4Li1XWJRT_7VWHbTd2s"
],
"nt": "2",
"n": [
"ETNZH3ULvYawyZ-i0d8JZU6JR2nmAoAfSVPzhzS6b5CM",
"EYAfSVPzhzaU6JR2nmoTNZH3ULvwyZb6b5CMi0d8JZAS",
"EnmwyZdi0d8JZAoTNZYAfSVPzhzaU6JR2H3ULvS6b5CM"
]
}
Attached indexed signatures might look like:
-AADAA0ABxxx...xxx0ACByyy...yyy
Where:
-AAD: Count code indicating 3 indexed signatures followAA: First signature at index 00AB: Second signature at index 10AC: Third signature at index 2Indexed signatures extend beyond controller signatures to witness signatures. When witnesses provide receipts for key events, they attach their own signatures as indexed signatures:
{
"v": "KERI10JSON000091_",
"t": "rct",
"d": "EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
"i": "EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
"s": "0"
}
Attached witness indexed signatures:
-AABAA0ABxxx...xxx0ACByyy...yyy
The controller can determine which specific witness signed by looking up the index in their configured witness list for that event. This enables:
Interaction events (ixn) also use indexed signatures when anchoring external data:
{
"v": "KERI10JSON000138_",
"t": "ixn",
"d": "E8KY1sKmgyjAiUDdUBPNPyrSz_ad_Qf9yzhDNZlEKiMc",
"i": "EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
"s": "2",
"p": "EH7Oq9oxCgYa-nnNLvwhp9sFZpALILlRYyB-6n4WDi7w",
"a": [
{
"i": "EJJR2nmwyZ2i0dzaU6ULvS6b5CM8JZAoTNZH3YAfSVPzh",
"s": "0",
"d": "ELccvO_JJpvm2Fz-B4Li1XWJRT_7VWHbTd2sEe5T5YEZ"
}
]
}
The attached indexed signatures prove which subset of the multi-sig group authorized this anchoring operation.
In ACDC verifiable credentials, indexed signatures appear in CESR Proof Signatures:
{
"v": "ACDC10JSON000197_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
"s": "EBKValuMGPmwdSm3dpiXAQZHgGqWwaBqWDAKv3VqepLg",
"a": {
"d": "ELccvO_JJpvm2Fz-B4Li1XWJRT_7VWHbTd2sEe5T5YEZ",
"i": "EJJR2nmwyZ2i0dzaU6ULvS6b5CM8JZAoTNZH3YAfSVPzh",
"LEI": "254900OPPU84GM83MG36"
}
}
The CESR proof attachment includes indexed signatures proving which keys from the issuer's multi-sig AID authorized the credential issuance.
Verifying an indexed signature follows a deterministic algorithm:
Extract components from the CESR primitive:
k field): Ordered list of public keyskt field): Required signature countUse the index to retrieve the corresponding public key from the current keys list:
public_key = current_keys[index]
If the index is out of bounds, the signature is invalid.
Perform signature verification using the identified public key:
is_valid = verify_signature(
public_key=public_key,
message=event_bytes,
signature=signature_bytes
)
For Ed25519, this involves:
After verifying all attached indexed signatures, confirm that the count of valid signatures meets or exceeds the threshold:
valid_count = sum(1 for sig in signatures if verify(sig))
is_authorized = valid_count >= threshold
Only if threshold is satisfied is the event considered properly authorized.
A cigar is an un-indexed signature primitive used in single-signature scenarios where no index is needed. The key differences:
Both use the same underlying signature algorithms (Ed25519, ECDSA) but differ in their CESR encoding structure.
A signer is the CESR primitive representing a private key. It has the ability to create both:
The signer encapsulates the private key material and provides methods for generating signatures with or without index information.
A verfer represents a public key and has the ability to verify signatures. During indexed signature verification, the verifier:
A diger represents a cryptographic digest. In multi-sig scenarios, digers appear in:
The index in an indexed signature may correspond to the position of a diger in the next keys list during partial rotation.
Implementations must validate that the index value is within the bounds of the current keys list:
if index < 0 or index >= len(current_keys):
raise InvalidIndexError(f"Index {index} out of bounds")
Out-of-bounds indices indicate either:
Before accepting an event, implementations must verify threshold satisfaction:
valid_signatures = [sig for sig in signatures if verify(sig)]
if len(valid_signatures) < threshold:
raise InsufficientSignaturesError(
f"Required {threshold}, got {len(valid_signatures)}"
)
Implementations should detect and reject duplicate indices in the signature set:
indices = [sig.index for sig in signatures]
if len(indices) != len(set(indices)):
raise DuplicateIndexError("Duplicate signature indices detected")
Duplicate indices may indicate:
For advanced multi-sig schemes with fractional weights, implementations must:
weights = [1, 1, 2] # Key at index 2 has weight 2
total_weight = sum(weights[sig.index] for sig in valid_signatures)
threshold_weight = parse_threshold("2/3") * sum(weights)
if total_weight < threshold_weight:
raise InsufficientWeightError()
During partial rotation, only a subset of pre-rotated keys may be exposed. Implementations must:
For high-throughput scenarios, implementations can optimize indexed signature verification:
Batch verification: Ed25519 supports efficient batch verification of multiple signatures:
verify_batch(
public_keys=[keys[sig.index] for sig in signatures],
messages=[event_bytes] * len(signatures),
signatures=[sig.raw for sig in signatures]
)
Parallel verification: Independent signature verifications can be parallelized:
with ThreadPoolExecutor() as executor:
results = executor.map(verify_signature, signatures)
valid_count = sum(results)
Caching: Frequently verified events can have their verification results cached:
cache_key = (event_digest, frozenset(sig.index for sig in signatures))
if cache_key in verification_cache:
return verification_cache[cache_key]
Timing attacks: Implementations should use constant-time comparison for signature verification to prevent timing side-channels.
Index substitution: The CESR encoding cryptographically binds the index to the signature through the self-framing structure, but implementations should validate this binding.
Replay protection: Indexed signatures on events include the event's sequence number and prior event digest, preventing replay across different events.
Key compromise: If a key at a specific index is compromised, only signatures from that index are affected. The multi-sig threshold provides defense-in-depth.
Indexed signatures represent a fundamental innovation in KERI's approach to multi-signature authorization. By embedding index information directly in the signature primitive, KERI achieves:
The indexed signature primitive demonstrates KERI's design philosophy of creating self-describing, composable cryptographic primitives that enable both human readability (text domain) and machine efficiency (binary domain) while maintaining rigorous security properties.