A context-specific CESR encoding scheme that uses a two-character text code to compactly represent signatures in thresholded multi-signature schemes, where the first character identifies the signature type and the second character encodes a Base64 integer index pointing to the corresponding public key in an ordered set.
Related Concepts
No related concepts available
Comprehensive Explanation
dual-indexed-codes
Technical Definition
Dual-indexed codes represent a specialized encoding mechanism within the CESR (Composable Event Streaming Representation) framework, specifically designed to address the common use case of thresholded multi-signature schemes. This compact coding approach provides an efficient method to associate each signature with its corresponding public key through embedded indexing, eliminating the need for separate mapping structures while maintaining CESR's composability properties.
Formal Definition
A dual-indexed code is a two-character text domain primitive in CESR that encodes both:
The signature type and encoding scheme (first character)
An integer index reference to a public key in an ordered set (second character)
This encoding scheme is optimized for signatures with a 64-byte raw binary size, which results in a pad size of 2, naturally accommodating the two-character text code structure required for efficient stream processing.
Dual-indexed codes support a maximum of 64 keys in the indexed set due to the single Base64 character encoding of the index (6 bits = 2^6 = 64 possible values). Implementations must:
Validate that key set size does not exceed 64 keys
Use alternative CESR encoding schemes for larger key sets
Document this limitation in multi-sig configuration
Ordered Key Set Management
The effectiveness of dual-indexed codes depends on maintaining a consistent ordered key set across all participants:
Key order must be deterministic and agreed upon
Typically established in inception or rotation events
Order must be preserved across all signature verification contexts
Changes to key order require new establishment events
Threshold Verification Complexity
Post-2022 rotation rules require verifying signatures against two threshold types:
Prior-next-threshold: Threshold from previous establishment event's next key commitments
Current-signing-threshold: Threshold for current key state
Implementations must:
Track both threshold values from the key state
Verify sufficient signatures meet both thresholds when applicable
Handle the case where rotation uses keys not in prior next key digests
Stream Parsing Considerations
When parsing CESR streams containing dual-indexed codes:
The two-character code enables cold-start parsing without prior context
Type code (first character) determines signature length and format
Index (second character) must be decoded from Base64 to integer
Signature data follows immediately after the two-character code
Count codes may precede groups of dual-indexed signatures
Performance Optimization
For high-performance implementations:
Pre-compute key lookups: Build index-to-key mapping tables from key state
Verification optimization: Allows validators to quickly identify which public key corresponds to each signature
Cryptographic Properties
Underlying Signature Schemes
Dual-indexed codes are designed to work with popular signature formats that produce 64-byte raw binary signatures. This size characteristic is fundamental to the encoding scheme's efficiency. Common signature schemes that fit this profile include:
Ed25519 signatures: 64-byte signatures from EdDSA using Curve25519
ECDSA signatures: Certain elliptic curve signature formats
Other 64-byte signature schemes: Any cryptographic signature producing 64 raw bytes
Security Properties
The dual-indexed code mechanism itself does not alter the cryptographic security properties of the underlying signatures. Instead, it provides:
Integrity preservation: The index association is cryptographically bound through the signature verification process
Non-repudiation: Each signature remains individually verifiable against its indexed public key
Threshold enforcement: Supports verification of threshold requirements in multi-sig schemes
Duplicity detection: Enables detection of conflicting signatures from the same key index
Key/Output Sizes
Raw binary signature size: 64 bytes (512 bits)
Pad size: 2 (derived from 64-byte alignment in Base64 encoding)
Text code length: 2 characters
Index encoding: Single Base64 character (6 bits, supporting indices 0-63)
Data Format & Encoding
CESR Encoding Structure
The dual-indexed code leverages CESR's text domain encoding to achieve efficient signature-to-key mapping:
Two-Character Code Composition
First Character (Selector and Type Code):
Acts as the derivation code identifying the signature type
Specifies the cryptographic algorithm or suite used
Determines how the signature should be interpreted and verified
Maintains CESR's self-framing property
Second Character (Base64-Encoded Index):
Contains the integer index as a Base64-encoded value
Points to the specific public key in an ordered set
Supports indices from 0 to 63 (single Base64 character range)
Enables immediate key lookup without additional metadata
Text Domain Representation
In CESR's text domain, a dual-indexed code appears as a two-character prefix followed by the Base64-encoded signature data:
[Type Code][Index][Base64 Signature Data]
For example, if the type code is 'A' and the index is 3 (Base64 'D'), the complete encoded signature would begin with "AD" followed by the signature's Base64 representation.
Binary Domain Representation
In CESR's binary domain, the dual-indexed code maintains equivalent information density:
The type code and index are encoded in the binary primitive header
The 64-byte raw signature follows the header
The pad size of 2 ensures proper alignment for binary stream processing
Group codes can aggregate multiple dual-indexed signatures for efficient processing
Usage in KERI/ACDC
Multi-Signature Event Signing
Dual-indexed codes are primarily used in KERI establishment events that require multiple signatures:
Inception Events
When creating a multi-sig AID, the inception event may include signatures from multiple initial controlling keys. Each signature uses a dual-indexed code to indicate which key from the initial key set produced that signature.
Rotation Events
The 2022 evolution of KERI's rotation rules created the forcing function that necessitated dual-indexed codes. The new rotation mechanism allows:
Rotation to keys not in the prior next key digests
Verification against both prior-next-threshold and current-signing-threshold
This flexibility requires dual-indexed codes to clearly identify which keys (current or pre-rotated) are signing the rotation event, enabling proper threshold verification.
Count codes: Specify how many dual-indexed signatures follow
Group codes: Enable pipelining of signature groups
Composition: Multiple dual-indexed signatures can be framed as a group for efficient stream processing
Derivation Codes
The first character of a dual-indexed code is a derivation code that:
Identifies the cryptographic primitive type
Specifies the signature algorithm
Determines verification procedures
Maintains CESR's self-describing property
Implementation Context
KERIpy Evolution
The introduction of dual-indexed codes in CESR was directly driven by changes in KERIpy, the Python reference implementation of KERI:
Pre-2022 Implementation:
Control authority changes required two rotation events
Simpler threshold verification model
Less flexible key rotation constraints
Post-2022 Implementation:
Control authority changes possible with one rotation event
Rotation to keys not in prior next key digests allowed
Dual threshold verification (prior-next-threshold and current-signing-threshold)
Dual-indexed codes required to support this enhanced flexibility
This evolution demonstrates how protocol refinements in KERI drive corresponding changes in the underlying CESR serialization mechanisms to maintain security guarantees while improving operational efficiency.
Check both current-signing-threshold and prior-next-threshold if applicable
Accept event only if all threshold requirements are satisfied
Architectural Significance
Dual-indexed codes exemplify CESR's design philosophy of maximizing information density while preserving composability. By embedding key index information directly in the signature encoding, KERI achieves:
Reduced protocol overhead: No separate index mapping required
Improved scalability: Efficient processing of multi-sig events
Maintained security: No compromise of cryptographic properties
This encoding technique demonstrates how careful attention to data representation can significantly impact the efficiency and elegance of cryptographic protocols, particularly in streaming and event-driven architectures like KERI.
Error Handling
Implementations should handle these error conditions:
Invalid index: Index exceeds key set size
Missing key: Indexed key not present in current key state
Threshold failure: Insufficient verified signatures to meet thresholds
Type mismatch: Signature type incompatible with indexed key type
Malformed encoding: Invalid Base64 or incorrect primitive structure
Interoperability Requirements
To ensure interoperability across KERI implementations:
Follow CESR specification exactly for encoding/decoding
Maintain consistent key ordering conventions
Support all standard signature types with 64-byte raw size
Implement both text and binary domain representations
Preserve composability properties in stream processing