Algorithm Support

Verfers support multiple cryptographic signature schemes through CESR's derivation code system. The KERI specification and CESR specification define support for various algorithms including:

• Ed25519: Edwards-curve Digital Signature Algorithm using Curve25519, providing 128-bit security
• ECDSA: Elliptic Curve Digital Signature Algorithm with secp256k1 and secp256r1 curves
• Post-quantum algorithms: Support for quantum-resistant signature schemes as part of KERI's crypto-agility

The specific algorithm is encoded in the derivation code prefix, making each verfer self-typing—the type information travels with the data.

Security Properties

Verfers inherit the security properties of their underlying signature schemes:

• Unforgeability: Computationally infeasible to generate valid signatures without the corresponding private key
• Non-repudiation: Signatures verified by a verfer provide cryptographic proof of authorship
• Collision resistance: The binding between verfer and its corresponding signer (private key) is cryptographically strong

Key Sizes

Key sizes vary by algorithm:

• Ed25519: 32-byte (256-bit) public keys
• secp256k1: 33-byte compressed or 65-byte uncompressed public keys
• secp256r1: Similar sizes to secp256k1

The CESR encoding adds the derivation code prefix, resulting in slightly larger serialized representations.

Data Format & Encoding

CESR Encoding Structure

A verfer follows CESR's qualified primitive format, consisting of:

1. Derivation code: A prefix indicating the cryptographic algorithm and encoding parameters
2. Encoded key material: The public key encoded in either Base64 (text domain) or binary (binary domain)

The derivation code serves multiple purposes:

• Identifies the signature algorithm (e.g., Ed25519, ECDSA)
• Specifies the encoding format
• Enables self-framing—parsers can determine the primitive's length without external information

Text Domain Representation

In the text domain, verfers are encoded as Base64 URL-safe strings with the derivation code prepended. For example, an Ed25519 verfer might appear as:

DKxy2sgzfplyr-tgwIxS19f2OchFHtLwPWD3v4oYimBx

Where:

• D is the one-character derivation code for Ed25519
• The remaining characters are the Base64-encoded public key

Binary Domain Representation

In the binary domain, verfers use a compact binary encoding where the derivation code is represented as binary values rather than text characters. This provides more efficient storage and transmission while maintaining the same semantic information.

Composability

CESR's composability property ensures that verfers can be concatenated with other primitives in either text or binary domains and converted between domains without loss of information or boundary corruption. This is achieved through careful alignment of encoding boundaries and the use of derivation codes that preserve separability during domain transformations.

Usage in KERI/ACDC

Establishment Events

Verfers appear prominently in establishment events—inception and rotation events that define or change the key state of an AID.

Inception events include:

• Current key verfers (keys field): The public keys that currently control the identifier
• Next key digests (nxt field): Digests of pre-rotated keys, though these are digers rather than verfers

Rotation events include:

• New current key verfers: The rotated-in public keys that now control the identifier
• New next key digests: Digests of the next set of pre-rotated keys

The verfers in establishment events define the authoritative key set that can sign subsequent events and messages.

Multi-Signature Configurations

In multi-signature AIDs, multiple verfers are specified in the keys field along with a signing threshold. For example, a 2-of-3 multisig configuration would include three verfers and specify that signatures from at least two of the corresponding signers are required for valid event signing.

The MultiHab architecture in KERIpy demonstrates how verfers are used to construct multi-signature establishment events, with helper methods to extract verfers from signing member identifiers (smids).

Signature Verification

The primary operational use of verfers is signature verification. When a validator receives a signed key event message, the verification process involves:

1. Extracting the verfer(s) from the current key state of the AID
2. Parsing attached signatures (sigers or cigars)
3. Using the verfer to cryptographically verify that each signature was created by the corresponding private key
4. Checking threshold satisfaction for multi-signature configurations

This verification establishes the authenticity and non-repudiation of the event.

Witness and Watcher Infrastructure

Verfers are used to identify and verify witnesses and watchers in KERI's distributed infrastructure:

• Witness identifiers: Each witness has its own AID with associated verfers
• Witness receipts: Signed using the witness's private key, verified using its verfer
• Watcher validation: Watchers use verfers to verify events and receipts in promiscuous mode

ACDC Credentials

In ACDC (Authentic Chained Data Container) credentials, verfers appear in:

• Issuer AID verification: The issuer's current verfers are used to verify the credential's signature
• Issuee AID verification: When the issuee is identified by an AID, its verfers establish control
• Chained credential verification: Following edges between ACDCs requires verifying signatures using verfers from each issuer's key state

Related Primitives

Signer

The signer primitive is the private key counterpart to the verfer. While a verfer represents a public key and verifies signatures, a signer represents a private key and creates signatures. The relationship is:

• Key pair binding: Each verfer has a corresponding signer derived from the same seed or entropy source
• Asymmetric operations: Signers create sigers and cigars; verfers verify them
• Security separation: Signers must be protected and kept secret; verfers are public and freely distributed

Diger

The diger primitive represents a cryptographic digest (hash). Digers are closely related to verfers in KERI's pre-rotation mechanism:

• Next key digests: Instead of revealing future verfers directly, establishment events include digers of the next keys
• Commitment without exposure: This allows cryptographic commitment to future keys without exposing them to potential compromise
• Verification: When keys are rotated, the revealed verfers are hashed and compared to the previously committed digers

Siger and Cigar

These signature primitives are the outputs of signing operations that verfers verify:

• Siger: An indexed signature used in multi-signature contexts, including an index indicating which key in a set was used
• Cigar: An unindexed signature for single-signature scenarios
• Verification relationship: Verfers take sigers or cigars as input and return a boolean indicating signature validity

Salter

The salter primitive represents a seed and can generate new signers. The relationship to verfers is:

• Derivation chain: Salter → Signer → Verfer
• Deterministic generation: A salter can deterministically generate multiple signer/verfer pairs
• Key management: Salters enable hierarchical deterministic key derivation patterns

Implementation Considerations

Cesride Primitive Interface

According to the cesride documentation, all CESR primitives including verfers implement a standard method interface:

• .qb64(): Returns the qualified Base64 representation as a string
• .qb64b(): Returns the qualified Base64 representation as bytes
• .qb2(): Returns the qualified binary representation as bytes
• .code(): Returns the derivation code
• .raw(): Returns the raw unqualified key material as bytes

These methods enable consistent handling of verfers across different serialization contexts and programming languages.

Storage and Retrieval

In KERIpy, verfers are stored and retrieved through the key state management system:

• Key state records: Maintain the current and historical verfers for each AID
• Database storage: Verfers are persisted in LMDB databases as part of the KEL
• Caching: Frequently accessed verfers may be cached for performance

Multi-Language Support

The CESR encoding of verfers enables interoperability across different KERI implementations:

• KERIpy (Python): Native implementation with full verfer support
• KERI-Ox (Rust): Rust implementation via cesride
• WASM bindings: WebAssembly FFI enables JavaScript/TypeScript usage
• Cross-platform verification: Verfers encoded by one implementation can be verified by another

Performance Considerations

Verfer operations have different performance characteristics:

• Verification speed: Ed25519 verification is fast (~70,000 verifications/second on modern hardware)
• Encoding overhead: CESR encoding adds minimal overhead (1-2 bytes for derivation code)
• Batch verification: Some signature schemes support batch verification for multiple signatures

Security Best Practices

1. Verfer distribution: Verfers should be distributed through OOBIs or embedded in signed events
2. Key state validation: Always verify that a verfer matches the current key state before using it
3. Algorithm selection: Choose signature algorithms appropriate to the security requirements and threat model
4. Quantum readiness: Consider post-quantum verfers for long-term security

Conclusion

The verfer primitive is a foundational component of KERI's cryptographic architecture, providing the public key representation and signature verification capabilities essential for establishing secure attribution and control authority. Its integration with CESR encoding ensures that verfers are self-describing, composable, and interoperable across different implementations and serialization formats. Understanding verfers is essential for working with KERI key event logs, ACDC credentials, and the broader KERI ecosystem.

Security Considerations

• Validate derivation codes to ensure supported algorithms
• Verify key state currency before using verfers
• Protect against algorithm downgrade attacks by enforcing minimum security levels
• Consider post-quantum algorithms for long-term security requirements