Type Classification

In CESR encoding, digital signatures are classified as cryptographic primitives with specific derivation codes indicating:

• Signature algorithm (Ed25519, ECDSA secp256k1, Ed448)
• Whether the signature is indexed (for multi-sig scenarios) or non-indexed
• The encoding domain (text or binary)

Cryptographic Properties

Underlying Algorithms

KERI supports multiple signature schemes with different security properties:

Ed25519 (Edwards-curve Digital Signature Algorithm):

• Curve: Curve25519 (Edwards form)
• Key size: 256-bit private key, 256-bit public key
• Signature size: 512 bits (64 bytes)
• Security level: ~128-bit security
• Performance: Extremely fast signing and verification
• Properties: Deterministic signatures, small keys, constant-time operations

ECDSA secp256k1:

• Curve: secp256k1 (used in Bitcoin)
• Key size: 256-bit private key, 256-bit public key (compressed)
• Signature size: Variable (typically 70-72 bytes DER encoded)
• Security level: ~128-bit security
• Properties: Non-deterministic without RFC 6979, widely supported

Ed448 (Edwards-curve Digital Signature Algorithm):

• Curve: Curve448 (Edwards form)
• Key size: 448-bit private key, 448-bit public key
• Signature size: 912 bits (114 bytes)
• Security level: ~224-bit security
• Properties: Higher security margin, post-quantum resistance considerations

Security Properties

Existential Unforgeability under Chosen Message Attack (EUF-CMA): All supported signature schemes provide EUF-CMA security, meaning an adversary cannot forge a valid signature on any message, even after observing signatures on chosen messages.

Collision Resistance: Signature schemes rely on collision-resistant hash functions (SHA-256, SHA-512, SHAKE256) to digest messages before signing, preventing collision-based forgery attacks.

Non-Malleability: Ed25519 and Ed448 provide strong non-malleability guarantees. ECDSA requires careful implementation (RFC 6979 deterministic signatures) to prevent malleability attacks.

Key Compromise Impact: KERI's pre-rotation mechanism limits the impact of signing key compromise. Even if current signing keys are compromised, the attacker cannot forge rotation events because the next rotation keys are cryptographically hidden through digest commitments.

Key/Output Sizes

Ed25519:

• Private key: 32 bytes (256 bits)
• Public key: 32 bytes (256 bits)
• Signature: 64 bytes (512 bits)
• CESR encoded signature: 88 characters (text domain)

ECDSA secp256k1:

• Private key: 32 bytes (256 bits)
• Public key: 33 bytes compressed (264 bits)
• Signature: ~72 bytes DER encoded
• CESR encoded signature: 88 characters (text domain)

Ed448:

• Private key: 57 bytes (456 bits)
• Public key: 57 bytes (456 bits)
• Signature: 114 bytes (912 bits)
• CESR encoded signature: 152 characters (text domain)

Data Format & Encoding

CESR Encoding Format

CESR (Composable Event Streaming Representation) provides self-describing encoding for digital signatures through prepended derivation codes.

Non-Indexed Signatures (Cigars): Used for single-signature scenarios where no index is needed.

• Ed25519: Code 0B + 88-character Base64 signature
  • Example: 0BDKPtvB7t-Grh8DKPE5eeJRzkRTMOoRGVd2m18o8fLqM2j9kaxLhV3x8AQ
• ECDSA secp256k1: Code 0C + 88-character Base64 signature
• Ed448: Code 1AAE + 152-character Base64 signature

Indexed Signatures (Sigers): Used in multi-signature scenarios to indicate which key from a set produced the signature.

• Structure: Derivation code + index + signature material
• Index encoding: Indicates position in the key list
• Example: -AABAA (count code) + indexed signature attachment

Text and Binary Representations

Text Domain (Base64 URL-safe):

• Uses characters [A-Z, a-z, 0-9, -, _]
• Derivation code prepended to signature
• Length must be multiple of 4 characters (24-bit alignment)
• Human-readable, suitable for JSON serialization

Binary Domain:

• Raw bytes with binary derivation code prefix
• Length must be multiple of 3 bytes (24-bit alignment)
• Compact representation for efficient transmission
• Convertible to/from text domain without loss (composability property)

Derivation Codes

Derivation codes encode:

1. Signature algorithm: Ed25519, ECDSA, Ed448
2. Indexing: Whether signature includes multi-sig index
3. Domain: Text or binary encoding

Common Codes:

• 0B: Ed25519 non-indexed signature (64 bytes)
• 0C: ECDSA secp256k1 non-indexed signature
• 1AAE: Ed448 non-indexed signature (114 bytes)
• -AAB: Count code for indexed signature attachments

Usage in KERI/ACDC

In Key Event Messages

Every KERI key event message consists of:

1. Event body: JSON-serialized event data (inception, rotation, interaction)
2. Signature attachments: CESR-encoded signatures following the event body

Inception Event Signature:

{"v":"KERI10JSON...","t":"icp","d":"EAB...","i":"EAB...","s":"0",...}
-AABAA0BDKPtvB7t-Grh8DKPE5eeJRzkRTMOoRGVd2m18o8fLqM2j9kaxLhV3x8AQ

The signature attachment begins with -AAB (count code indicating one indexed signature follows), then the indexed signature.

Rotation Event Signature: Rotation events must be signed by keys from the current authoritative set (not the next pre-rotated keys). This ensures that rotation authority is proven through possession of currently active keys.

Interaction Event Signature: Interaction events (non-establishment events) are signed by current keys to anchor external data to the KEL without changing key state.

In ACDC Credentials

ACDCs use an indirect signature mechanism:

1. ACDC SAID Generation: The ACDC's Self-Addressing Identifier is computed from its content
2. KEL Event Anchoring: The ACDC SAID is included in a KEL event's seal section
3. KEL Event Signing: The KEL event (containing the ACDC SAID) is digitally signed
4. Transitive Verification: Verifying the KEL event signature cryptographically commits to the ACDC

This design enables:

• Key rotation resilience: ACDCs remain verifiable after issuer key rotation
• Compact credentials: ACDCs don't carry direct signatures, reducing size
• Unified verification: ACDC verification reduces to KEL verification

Common Usage Patterns

Single-Signature AID:

• One key pair controls the identifier
• Threshold kt = "1" (one signature required)
• Simple signature attachment with code 0B for Ed25519

Multi-Signature AID:

• Multiple key pairs control the identifier
• Threshold kt = "2" or higher (M-of-N signatures required)
• Indexed signatures with position indicators
• Example: 3-of-5 multisig requires 3 indexed signatures from the 5-key set

Weighted Multi-Signature:

• Keys have fractional weights
• Threshold expressed as fractional value
• Signatures must satisfy weight threshold
• Example: kt = ["1/2", "1/2", "1/4", "1/4"] with threshold "1"

Verification Procedures

Step 1: Extract Public Key:

• For self-certifying identifiers, derive public key from the AID prefix
• For subsequent events, retrieve current key state from KEL
• For multi-sig, retrieve all keys in the current authoritative set

Step 2: Verify Signature Cryptographically:

• Parse CESR-encoded signature to extract raw signature bytes
• Apply signature verification algorithm: Verify(pk, message, signature)
• For Ed25519: Use edwards25519 curve verification
• For ECDSA: Use secp256k1 curve verification

Step 3: Verify Threshold Satisfaction:

• For single-sig: One valid signature required
• For multi-sig: Count valid signatures and verify threshold met
• For weighted multi-sig: Sum weights of valid signatures and verify threshold met

Step 4: Verify Event Integrity:

• Verify event digest matches the d field (SAID)
• Verify prior event digest matches the p field (hash chaining)
• Verify sequence number increments correctly

Step 5: Verify Key State Consistency:

• Verify signing keys match current authoritative keys from prior establishment event
• For rotation events, verify next key digest from prior event matches revealed keys
• Verify witness threshold and witness set consistency

Related Primitives

Public Keys

Digital signatures are inseparable from public key cryptography. The public key serves as the verification key for signatures created with the corresponding private key. In KERI, public keys are encoded as CESR primitives with derivation codes indicating the key type:

• D: Ed25519 public verification key
• 1AAB: ECDSA secp256k1 public verification key
• 1AAD: Ed448 public verification key

The relationship is complementary: private keys sign, public keys verify.

Digests (Hashes)

Digital signature schemes typically sign a digest (cryptographic hash) of the message rather than the message itself. This provides:

• Fixed-size input: Regardless of message length, digest is fixed size
• Efficiency: Signing a 32-byte digest is faster than signing megabytes of data
• Collision resistance: Prevents collision-based forgery attacks

KERI uses digests extensively:

• Event digests: The d field in every event is a SAID (self-addressing identifier)
• Prior event digests: The p field creates hash chaining
• Next key digests: The n field commits to pre-rotated keys

The relationship is compositional: signatures are applied to digests, not raw data.

Indexed Signatures (Sigers)

In multi-signature scenarios, indexed signatures extend basic signatures with position information:

• Index field: Indicates which key from the authoritative set produced the signature
• Threshold verification: Enables verification that M-of-N signatures are present
• Efficient verification: Verifier knows which public key to use without trial-and-error

The relationship is specialization: indexed signatures are digital signatures with additional metadata.

Seals

Seals are cryptographic commitments that anchor external data to KEL events:

• Event seals: Commit to other events (delegation, interaction)
• Digest seals: Commit to arbitrary data via digest
• ACDC seals: Commit to credential SAIDs

Seals are signed as part of the KEL event containing them, creating transitive signature coverage. The relationship is hierarchical: signatures cover seals, seals cover external data.

Receipts

Witness receipts are signatures from designated witnesses confirming observation of key events:

• Receipt structure: References the event being receipted (via SAID)
• Witness signature: Proves the witness observed and validated the event
• Duplicity detection: Conflicting receipts indicate duplicitous behavior

The relationship is attestation: receipts are signatures that attest to event observation.

Implementation Considerations

Signature Generation

Deterministic Signatures: Ed25519 and Ed448 are inherently deterministic (same message + key = same signature). ECDSA requires RFC 6979 deterministic nonce generation to avoid nonce reuse vulnerabilities.

Key Management:

• Private keys must be stored securely (encrypted keystores, HSMs, secure enclaves)
• Key generation requires cryptographically secure random number generators (CSPRNGs)
• Minimum 128 bits of entropy for key generation

Signature Serialization:

• Use CESR encoding for all signatures in KERI/ACDC systems
• Maintain 24-bit alignment for composability
• Include appropriate derivation codes for algorithm identification

Signature Verification

Public Key Retrieval:

• For self-certifying identifiers: Extract public key from AID prefix using derivation code
• For rotated identifiers: Retrieve current key state by processing KEL up to the event being verified
• Cache key states for performance, but validate cache consistency

Batch Verification: For performance, implement batch verification when verifying multiple signatures:

• Ed25519 supports efficient batch verification
• Verify multiple signatures in a single operation
• Significant performance improvement for witness receipt verification

Error Handling:

• Invalid signatures must cause immediate rejection
• Threshold failures must be clearly reported
• Distinguish between cryptographic failures and threshold failures

Multi-Signature Coordination

Signature Collection:

• In multi-sig scenarios, collect signatures from all required signers
• Use indexed signatures to track which keys have signed
• Implement timeout mechanisms for signature collection

Threshold Verification:

• Verify that collected signatures satisfy the threshold requirement
• For weighted thresholds, sum weights and verify threshold met
• Reject events that don't meet threshold even if some signatures are valid

Partial Rotation: KERI supports partial rotation where only a threshold-satisfying subset of next keys participates in rotation:

• Next keys field n is a list of digests (not XORed)
• Rotation event reveals only participating keys
• Non-participating keys remain hidden for future rotations

Performance Optimization

Signature Caching:

• Cache verification results for frequently accessed events
• Invalidate cache on key rotation or configuration changes
• Use content-addressed caching (key = event SAID)

Parallel Verification:

• Verify independent signatures in parallel
• Use thread pools or async operations for concurrent verification
• Particularly beneficial for witness receipt verification

Hardware Acceleration:

• Leverage CPU instruction sets (AES-NI, AVX2) for cryptographic operations
• Use hardware security modules (HSMs) for high-security deployments
• Consider GPU acceleration for batch verification in high-throughput scenarios

Security Considerations

Timing Attacks:

• Use constant-time signature verification implementations
• Avoid branching on secret data during cryptographic operations
• Ed25519 and Ed448 are designed for constant-time operation

Side-Channel Attacks:

• Protect private keys from side-channel leakage (power analysis, EM radiation)
• Use secure key storage (encrypted keystores, HSMs)
• Implement key access controls and audit logging

Quantum Resistance:

• Current signature schemes (Ed25519, ECDSA) are vulnerable to quantum attacks
• KERI's pre-rotation provides post-quantum protection for rotation authority
• Plan migration to post-quantum signature schemes (SPHINCS+, Dilithium)
• Ed448 provides higher security margin as interim measure

Testing and Validation

Test Vectors:

• Use standard test vectors for signature algorithm implementations
• Verify interoperability with other KERI implementations
• Test edge cases (empty messages, maximum-length messages)

Fuzzing:

• Fuzz signature verification code with malformed signatures
• Test threshold verification with invalid signature combinations
• Verify robust error handling for corrupted CESR encodings

Compliance Testing:

• Verify compliance with KERI specification requirements
• Test CESR encoding/decoding round-trip correctness
• Validate composability property for concatenated signatures

Threshold Verification:

• Implement flexible threshold checking (M-of-N, weighted)
• Verify that collected signatures satisfy the threshold requirement
• Support fractional weights for weighted multi-sig
• Reject events that don't meet threshold even if some signatures are valid

Signature Collection:

• Implement asynchronous signature collection for distributed signers
• Use escrow mechanisms to temporarily store partially-signed events
• Implement timeout and retry logic for signature collection
• Provide clear status reporting for signature collection progress

Key State Management

Current Key Retrieval:

• Maintain efficient key state cache indexed by AID and sequence number
• Invalidate cache on key rotation events
• For verification, retrieve key state at the sequence number of the event being verified
• Handle key state queries for both current and historical events

Pre-Rotation Verification:

• Verify that rotation events reveal keys matching prior next key digests
• Check that revealed keys hash to the committed digests
• Support partial rotation where only threshold-satisfying subset of keys is revealed
• Maintain hidden keys for future rotations

Performance Optimization

Batch Verification:

• Implement batch verification for Ed25519 signatures when verifying multiple signatures
• Use vectorized operations for parallel signature verification
• Particularly important for witness receipt verification
• Can provide 2-3x performance improvement over individual verification

Caching Strategies:

• Cache verification results for frequently accessed events
• Use content-addressed caching (key = event SAID)
• Implement LRU eviction for cache management
• Invalidate cache entries on configuration changes

Hardware Acceleration:

• Leverage CPU instruction sets (AES-NI, AVX2) for cryptographic operations
• Use hardware security modules (HSMs) for high-security deployments
• Consider GPU acceleration for high-throughput scenarios
• Profile cryptographic operations to identify bottlenecks

Security Best Practices

Private Key Protection:

• Store private keys in encrypted keystores with strong encryption (AES-256)
• Use hardware security modules (HSMs) for high-value keys
• Implement key access controls and audit logging
• Never log or transmit private keys in plaintext
• Use secure memory wiping for key material after use

Constant-Time Operations:

• Use constant-time signature verification implementations
• Avoid branching on secret data during cryptographic operations
• Verify that cryptographic library implementations are constant-time
• Test for timing side-channels using statistical analysis

Nonce Generation (ECDSA):

• Always use RFC 6979 deterministic nonce generation for ECDSA
• Never reuse nonces across different messages
• Verify that ECDSA implementation uses deterministic nonces
• Consider using Ed25519 instead to avoid nonce management complexity

Error Handling

Signature Verification Failures:

• Distinguish between cryptographic failures and threshold failures
• Provide detailed error messages for debugging
• Log verification failures for security monitoring
• Implement rate limiting to prevent verification DoS attacks

Malformed Signature Handling:

• Validate CESR encoding before attempting verification
• Check derivation codes match expected algorithms
• Verify signature length matches algorithm requirements
• Reject malformed signatures early to avoid cryptographic library errors

Threshold Failures:

• Clearly report which signatures are valid and which are invalid
• Indicate how many additional signatures are needed to meet threshold
• Provide actionable error messages for multi-sig coordination
• Implement retry mechanisms for transient failures

Testing Requirements

Test Vectors:

• Use standard test vectors from algorithm specifications (RFC 8032 for Ed25519)
• Verify interoperability with other KERI implementations
• Test edge cases (empty messages, maximum-length messages, boundary conditions)
• Validate CESR encoding/decoding correctness

Fuzzing:

• Fuzz signature verification code with malformed signatures
• Test threshold verification with invalid signature combinations
• Verify robust error handling for corrupted CESR encodings
• Use coverage-guided fuzzing to maximize code coverage

Compliance Testing:

• Verify compliance with KERI specification requirements
• Test CESR composability property for concatenated signatures
• Validate 24-bit alignment for all encoded signatures
• Verify round-trip conversion between text and binary domains

Migration and Upgrade Paths

Algorithm Agility:

• Design systems to support multiple signature algorithms
• Use derivation codes to identify algorithm in use
• Implement algorithm negotiation for multi-party scenarios
• Plan for migration to post-quantum signature schemes

Post-Quantum Preparation:

• Monitor NIST post-quantum standardization process
• Plan migration to post-quantum algorithms (SPHINCS+, Dilithium)
• Leverage KERI's pre-rotation for post-quantum protection of rotation authority
• Consider hybrid schemes during transition period

Backward Compatibility:

• Maintain support for older signature algorithms during transition
• Implement version negotiation for algorithm selection
• Provide clear deprecation timelines for older algorithms
• Test interoperability across algorithm versions