For ACDC (Authentic Chained Data Container) credentials, signers enable:

• Credential issuance: Signing credential data to establish proof-of-authorship
• Presentation signing: Creating signatures for credential presentations
• Chain verification: Signing edges that link ACDCs in verifiable chains

Type Classification

The signer is classified as a cryptographic material primitive in CESR's taxonomy. It belongs to the category of primitives that perform cryptographic operations (as opposed to primitives that represent digests or verification keys). The signer is specifically a signing primitive that operates in the Raw Domain for cryptographic operations while supporting serialization to both Text Domain and Binary Domain through CESR encoding.

Cryptographic Properties

Underlying Algorithms

Signers in KERI implementations support multiple cryptographic signature schemes, with the specific algorithm indicated by the derivation code prepended to the encoded key material. Common algorithms include:

Ed25519 (EdDSA):

• The most commonly used signature scheme in KERI
• Based on Curve25519 elliptic curve
• Provides approximately 128 bits of cryptographic strength
• Deterministic signature generation
• Fast signing and verification operations

ECDSA secp256k1:

• Used for Bitcoin/Ethereum compatibility
• Based on secp256k1 elliptic curve
• Also provides approximately 128 bits of security
• Non-deterministic unless using RFC 6979

Post-Quantum Algorithms:

• KERI's architecture supports future post-quantum signature schemes
• The pre-rotation mechanism provides post-quantum security even with current algorithms

Security Properties

Signers provide several critical security properties:

Non-repudiation: Signatures created by a signer are cryptographically bound to the private key, making it computationally infeasible for the signer to deny having created the signature. This property is fundamental to KERI's duplicity detection mechanisms.

Unforgeability: Without access to the private key, it is computationally infeasible to create valid signatures. This property relies on the hardness of the discrete logarithm problem (for elliptic curve schemes) or similar mathematical problems.

Key Isolation: The signer primitive encapsulates the private key, providing an abstraction layer that can enforce security policies around key usage. In production systems, signers may interface with Hardware Security Modules (HSMs) or Trusted Execution Environments (TEEs) to protect key material.

One-Time Use: KERI's security model emphasizes one-time, one-place, one-way key usage. Signers should ideally be used for a single signing operation and then rotated, particularly for establishment events that change key state.

Key/Output Sizes

For Ed25519 (the most common KERI signature scheme):

Private Key Size:

• Raw binary: 32 bytes (256 bits)
• CESR text encoding: 44 characters (including derivation code)
• CESR binary encoding: 33 bytes (including derivation code)

Signature Output Size:

• Raw signature: 64 bytes (512 bits)
• CESR text encoding for indexed signature (Siger): 88 characters
• CESR binary encoding for indexed signature: 66 bytes

The derivation code prepended to the key material indicates:

• The cryptographic algorithm used
• The key type (signing vs. verification)
• The encoding format

For example, the derivation code A indicates an Ed25519 signing key in CESR text format.

Data Format & Encoding

CESR Encoding Format

Signers follow CESR's qualified encoding approach, where cryptographic material is prepended with a derivation code that makes the primitive self-describing. This enables self-framing and composability properties essential to CESR streams.

Qualified Encoding Structure:

[Derivation Code][Encoded Key Material]

The derivation code serves multiple purposes:

1. Algorithm identification: Specifies which cryptographic algorithm the key uses
2. Type indication: Distinguishes signing keys from verification keys
3. Length determination: Enables parsers to extract the correct number of bytes/characters
4. Domain indication: Specifies whether the encoding is text or binary

Text and Binary Representations

Signers support dual-domain encoding, a core CESR feature:

Text Domain (T):

• Uses URL-safe Base64 character set: [A-Z, a-z, 0-9, -, _]
• Human-readable for debugging and logging
• Suitable for JSON serialization and text-based protocols
• Example Ed25519 signing key: AXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148

Binary Domain (B):

• Compact byte representation
• Efficient for network transmission and storage
• Maintains same logical structure as text domain
• Enables lossless round-trip conversion with text domain

Raw Domain (R):

• Represented as tuple: (derivation_code, raw_key_bytes)
• Used for actual cryptographic operations
• The raw key bytes are fed to cryptographic libraries
• Example: ("A", b'\x5e\xae\x98\xaa...') (32 bytes for Ed25519)

Derivation Codes

Common derivation codes for signers include:

Ed25519 Signing Keys:

• A: Ed25519 signing key (text domain, 44 characters)
• 0A: Ed25519 signing key (binary domain, 33 bytes)

ECDSA secp256k1 Signing Keys:

• M: ECDSA secp256k1 signing key (text domain)
• 0M: ECDSA secp256k1 signing key (binary domain)

The derivation code system is extensible, allowing new signature schemes to be added without breaking existing implementations. This cryptographic agility is essential for KERI's long-term security as new algorithms emerge and old ones become deprecated.

Alignment and Padding

CESR requires all primitives to align on 24-bit boundaries (the least common multiple of 6 bits for Base64 characters and 8 bits for bytes). For Ed25519 signing keys:

• Raw key: 32 bytes
• Pad size calculation: (3 - (32 mod 3)) mod 3 = 1
• One lead byte is prepended before Base64 encoding
• The derivation code replaces characters derived from the lead byte

This alignment ensures composability—concatenated primitives can be converted between text and binary domains without bit-level dependencies between adjacent primitives.

Usage in KERI/ACDC

In Which Event Types

Signers are used to create signatures for all KERI event messages:

Inception Events:

• The controller's signer creates the initial signature binding the AID to the inception event
• For self-addressing identifiers, the signer signs the event containing the AID itself
• Multi-sig inception requires multiple signers coordinating to meet the signing threshold

Rotation Events:

• Current signers sign the rotation event that introduces new keys
• The rotation event includes pre-rotated key digests for the next rotation
• Signers for the current keys must meet the current threshold
• The rotation establishes new signers for subsequent events

Interaction Events:

• Signers create signatures for non-establishment events
• These events anchor external data through seals
• Interaction events do not change key state but must be signed by current authoritative keys

Delegated Events:

• Delegated identifiers require signatures from both the delegate's signer and approval from the delegator
• The delegator's signer creates a seal in their KEL approving the delegate's event

Common Usage Patterns

Single-Signature Pattern:

1. Controller generates key pair using Salter
2. Signer primitive encapsulates private key
3. Event data is serialized
4. Signer.sign(event_data) produces signature
5. Signature is attached to event message
6. Verfer (public key) is published in KEL

Multi-Signature Pattern:

1. Multiple controllers each have their own Signer
2. Event data is shared among all signers
3. Each Signer creates an indexed signature (Siger)
4. Signatures are collected until threshold is met
5. All signatures are attached to the event
6. Each signature includes an index indicating which key signed

Custodial Signing Pattern:

1. Controller retains rotation authority (pre-rotated keys)
2. Custodial agent holds signing authority (current keys)
3. Agent's Signer signs routine operations
4. Controller's Signer only used for rotations
5. Enables secure delegation without full key transfer

Witness Receipt Pattern:

1. Controller's Signer signs key event
2. Event is sent to witnesses
3. Each witness's Signer creates a receipt signature
4. Receipts are collected to form KERL
5. Witnesses' signatures provide distributed consensus

Verification Procedures

While signers create signatures, verification uses the corresponding Verfer (public key) primitive:

Signature Verification Steps:

1. Extract the signature from the event message
2. Identify the signing key using the signature index (for multi-sig)
3. Retrieve the corresponding Verfer from the KEL
4. Use Verfer.verify(event_data, signature) to validate
5. Check that the signature satisfies the threshold requirement

Key State Verification:

1. Determine which keys were authoritative when the event was signed
2. For inception events, the AID prefix derives from the initial keys
3. For subsequent events, consult the KEL to find the current key state
4. Verify that the signing keys match the authoritative keys at that point in the KEL

Threshold Verification:

1. Count the number of valid signatures
2. Compare against the signing threshold specified in the most recent establishment event
3. For weighted thresholds, sum the weights of valid signatures
4. Ensure the threshold is met before accepting the event

Related Primitives

Complementary Primitives

Verfer (Public Key Primitive):

• The signer's public counterpart
• Used to verify signatures created by the signer
• Published in KELs while signers remain private
• Relationship: Asymmetric key pair (signer = private, verfer = public)

Salter (Seed Primitive):

• Generates signers from cryptographic seeds
• Enables hierarchical deterministic key derivation
• Relationship: Salter creates signers; one salter can generate multiple signers

Siger (Indexed Signature Primitive):

• Output of signer in multi-signature contexts
• Includes index to identify which key signed
• Relationship: Signer produces sigers as output

Cigar (Non-Indexed Signature Primitive):

• Output of signer in single-signature contexts
• No index needed when only one key signs
• Relationship: Signer produces cigars as output

Diger (Digest Primitive):

• Represents cryptographic hashes
• Used in pre-rotation commitments
• Relationship: Signers sign digests of events; pre-rotated keys are committed as digests

Composition Patterns

Signer + Salter Pattern:

Salter (seed) → generates → Signer (private key)
                          ↓
                    Verfer (public key)

This pattern enables key derivation from a single seed, reducing the burden of managing multiple private keys.

Signer + Threshold Pattern:

Multiple Signers → create → Multiple Sigers → aggregated → Threshold Satisfied

This pattern implements multi-signature schemes where M-of-N signatures are required.

Signer + Pre-rotation Pattern:

Current Signer → signs event → includes digest of Next Signer
                                              ↓
                                    Next Signer (unexposed)

This pattern provides post-quantum security by committing to future keys before they're exposed.

Signer + Delegation Pattern:

Delegator's Signer → approves → Delegate's Signer → signs delegated event

This pattern enables hierarchical key management and authority delegation.

Implementation Considerations

Key Generation and Storage

Signers must be generated from high-quality entropy sources:

Entropy Requirements:

• Minimum 128 bits of cryptographic strength
• Use CSPRNG (Cryptographically Secure Pseudorandom Number Generator)
• Avoid predictable sources like timestamps or process IDs

Storage Security:

• Private keys should never be stored in plaintext
• Use encrypted keystores with strong passcodes
• Consider HSM or TEE for high-value keys
• Implement key stretching for passcode-derived encryption keys

Signing Operations

Deterministic Signing:

• Ed25519 signatures are deterministic (same message + key = same signature)
• ECDSA requires RFC 6979 for deterministic signatures
• Determinism prevents certain side-channel attacks

Signature Caching:

• For performance, implementations may cache signatures for frequently-accessed events
• Cache invalidation must occur on key rotation
• Cached signatures must be verified against current key state

Concurrent Signing:

• Multi-signature scenarios require coordination among signers
• Implementations must handle partial signature sets
• Escrow mechanisms hold events until threshold is met

Security Best Practices

Key Rotation:

• Rotate signing keys regularly, especially after exposure
• Use pre-rotation to maintain identifier persistence
• Keep rotation keys in cold storage until needed

Key Separation:

• Use different signers for different purposes (signing vs. rotation)
• Implement partial rotation for custodial scenarios
• Separate hot keys (frequent use) from cold keys (rare use)

Audit Logging:

• Log all signing operations for security auditing
• Include timestamp, event type, and key identifier
• Protect audit logs from tampering

Key Compromise Detection:

• Monitor for duplicity (conflicting signatures)
• Implement watchers to detect unauthorized key usage
• Have key revocation procedures ready

Performance Optimization

Batch Signing:

• For high-throughput scenarios, batch multiple events
• Sign a Merkle root of multiple events
• Trade-off: increased latency for individual events

Hardware Acceleration:

• Use CPU instructions for elliptic curve operations (e.g., AVX2)
• Leverage hardware crypto accelerators when available
• Consider GPU acceleration for bulk signing operations

Parallel Signing:

• In multi-signature scenarios, signers can operate in parallel
• Coordinate through message passing or shared state
• Ensure thread-safe access to key material

Error Handling

Invalid Key Material:

• Validate key format before attempting signing operations
• Check derivation code matches expected algorithm
• Verify key length matches algorithm requirements

Signing Failures:

• Handle cryptographic library errors gracefully
• Distinguish between transient failures (retry) and permanent failures (key compromise)
• Log failures for security analysis

Threshold Failures:

• Detect when insufficient signatures are available
• Implement timeout mechanisms for multi-sig coordination
• Provide clear error messages indicating which signatures are missing

Error Handling

• Invalid key material: Validate derivation codes and key lengths before signing
• Cryptographic failures: Handle library errors gracefully and log for analysis
• Threshold failures: Provide clear diagnostics when multi-sig thresholds aren't met
• Key compromise: Have procedures ready for key revocation and recovery

Integration with CESR

Signers must properly implement CESR encoding:

• Derivation codes: Prepend appropriate codes for algorithm and domain
• 24-bit alignment: Ensure proper padding for composability
• Domain conversion: Support lossless conversion between text and binary domains
• Self-framing: Enable parsers to extract signer output without external schema

Testing Requirements

• Test vectors: Validate against known test vectors for each supported algorithm
• Round-trip encoding: Verify text ↔ binary conversion preserves key material
• Threshold scenarios: Test various M-of-N multi-signature configurations
• Key rotation: Verify proper handling of pre-rotation and key state changes
• Duplicity detection: Test that conflicting signatures are properly detected