A cigar is created by a Signer primitive, which represents a private key. The Signer has the capability to generate both cigars (unindexed signatures) and sigers (indexed signatures) depending on the signing context.

The cryptographic signature itself follows standard digital signature algorithms supported by KERI, including:

• Ed25519: Edwards-curve Digital Signature Algorithm using Curve25519
• ECDSA: Elliptic Curve Digital Signature Algorithm with secp256k1
• Ed448: Edwards-curve signatures using Curve448

The choice of algorithm is indicated by the derivation code that qualifies the signature primitive in its CESR encoding.

Security Properties

Cigars inherit the security properties of their underlying signature algorithms:

• Non-repudiation: The signature cryptographically binds the signer to the signed data
• Integrity: Any modification to the signed data invalidates the signature
• Authenticity: The signature can only be created by the holder of the corresponding private key
• Unforgeability: Computationally infeasible to forge without the private key

For Ed25519 signatures (the most common in KERI), the signature size is 64 bytes (512 bits), providing approximately 128 bits of security strength.

Verification Process

A cigar is verified using a Verfer primitive, which represents the corresponding public key. The verification process:

1. Extracts the raw signature bytes from the qualified CESR encoding
2. Applies the signature verification algorithm specified by the derivation code
3. Confirms the signature is valid for the given data and public key
4. Returns a boolean verification result

Data Format & Encoding

CESR Encoding Structure

Like all CESR primitives, a cigar follows the qualified encoding pattern:

[Derivation Code][Encoded Signature Material]

The derivation code is a short prefix (typically 1-4 characters in text domain) that specifies:

• The signature algorithm used
• The encoding format (Base64 or binary)
• The length of the signature material

This self-describing format enables parsers to extract the signature from a CESR stream without external schema information.

Text Domain Representation

In the text domain, cigars are encoded using Base64 URL-safe encoding. The complete representation includes:

• Derivation code: 1-4 Base64 characters indicating signature type
• Signature material: Base64-encoded signature bytes
• No padding: CESR eliminates the '=' padding character through careful alignment

For example, an Ed25519 signature cigar might appear as:

0BDKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqKqK

Where 0B is the derivation code for an Ed25519 signature, followed by the Base64-encoded 64-byte signature.

Binary Domain Representation

In the binary domain, cigars use a compact binary encoding:

• Derivation code: 1-2 bytes in binary form
• Signature material: Raw signature bytes
• Alignment: Properly aligned on 24-bit boundaries for composability

The binary representation is more compact than text encoding, making it suitable for bandwidth-constrained applications.

Standard Methods

All cigar primitives implement the standard cesride method interface:

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

These methods enable consistent handling across different encoding domains and facilitate composability in CESR streams.

Usage in KERI/ACDC

Single-Signature Contexts

Cigars are the appropriate signature primitive when:

• A single AID (Autonomic Identifier) is signing an event
• The AID uses a single-signature key state (not multi-sig)
• There is no ambiguity about which key created the signature

Key Event Signing

In KEL (Key Event Log) operations, cigars may be used for:

• Non-establishment events: Interaction events that don't change key state
• Single-controller identifiers: When the identifier is controlled by a single key pair
• Witness receipts: When a single witness signs a key event receipt

However, for establishment events (inception and rotation) in transferable identifiers, indexed signatures (sigers) are typically preferred even in single-signature scenarios to maintain consistency with multi-signature patterns.

ACDC Signatures

In ACDC (Authentic Chained Data Container) credentials:

• Cigars may be used when a single issuer signs a credential
• The signature is attached to the ACDC as part of the CESR proof signature mechanism
• The unindexed nature is appropriate when the issuer AID is single-sig

Attachment to Messages

Cigars are attached to messages as part of the attachment section:

1. The message body contains the data to be signed
2. The cigar is serialized in CESR format
3. The cigar is appended to the message as an attachment
4. Validators extract and verify the cigar against the message body

Verification Workflow

When a validator receives a message with a cigar attachment:

1. Parse the CESR stream to extract the cigar primitive
2. Identify the signing AID from the message context
3. Retrieve the current key state for that AID
4. Extract the public key (verfer) from the key state
5. Verify the cigar signature using the verfer
6. Confirm the signature is valid for the message body

Related Primitives

Siger (Indexed Signature)

The siger is the indexed counterpart to the cigar. Key differences:

• Siger includes index: Specifies which key in a multi-sig set created the signature
• Cigar has no index: Assumes single-signature context
• Siger is larger: Additional bytes for index information
• Siger is required for multi-sig: Enables verification of threshold signatures

In multi-signature AIDs, sigers are mandatory because validators must know which specific keys signed to verify threshold requirements. Cigars cannot be used in these contexts.

Signer (Private Key)

The Signer primitive is the source of cigars:

• Represents the private key material
• Has methods to create both cigars and sigers
• Determines which signature type to generate based on context
• Maintains the private key in secure storage

The relationship is: Signer.sign(data) → Cigar

Verfer (Public Key)

The Verfer primitive verifies cigars:

• Represents the public key corresponding to the Signer
• Has methods to verify both cigars and sigers
• Extracts from the AID's current key state
• Performs the cryptographic verification operation

The relationship is: Verfer.verify(data, cigar) → Boolean

Diger (Digest)

While not directly related to signature operations, Diger primitives often work alongside cigars:

• Cigars sign digests rather than raw data for efficiency
• Large data structures are hashed to a diger
• The cigar signs the diger value
• This enables compact signatures over large datasets

This pattern is common in ACDC credentials where the cigar signs the SAID (Self-Addressing Identifier) of the credential rather than the entire credential body.

Composition Patterns

Cigars participate in several CESR composition patterns:

• Concatenated primitives: Multiple cigars can be concatenated in a stream
• Grouped primitives: Cigars can be part of count-code delimited groups
• Nested streams: Cigars can appear in nested CESR structures
• Transposable attachments: Cigars can be transposed across envelope boundaries

These composition capabilities are fundamental to CESR's composability guarantees, enabling complex signature schemes while maintaining stream parsability.

Implementation Considerations

When to Use Cigars vs Sigers

Implementers must choose between cigars and sigers based on:

• Single-sig AIDs: Cigars are appropriate and more compact
• Multi-sig AIDs: Sigers are required for index information
• Consistency: Some implementations use sigers universally for uniformity
• Optimization: Cigars save bytes in single-signature scenarios

Storage and Transmission

Cigars should be:

• Stored in qualified CESR format to preserve derivation information
• Transmitted in the appropriate domain (text or binary) for the protocol
• Validated immediately upon receipt before further processing
• Cached with their verification results to avoid redundant computation

Error Handling

Implementations must handle:

• Invalid derivation codes: Reject cigars with unknown or malformed codes
• Signature verification failures: Clearly distinguish from parsing errors
• Key state mismatches: Ensure the verfer corresponds to the current key state
• Replay attacks: Cigars alone don't prevent replay; use sequence numbers

Performance Optimization

For high-throughput applications:

• Batch signature verifications when possible
• Use binary domain encoding to reduce parsing overhead
• Cache verfers to avoid repeated key state lookups
• Consider hardware acceleration for signature operations

Security Best Practices

• Never reuse cigars across different messages
• Validate the entire CESR stream structure, not just the signature
• Implement proper key rotation to limit signature exposure
• Use appropriate signature algorithms for the security requirements
• Protect Signer primitives with hardware security modules when possible

Error Handling Patterns

Implement robust error handling for:

• Parsing errors: Invalid derivation codes or malformed encodings
• Verification failures: Signature does not match data and public key
• Key state errors: Missing or invalid verfer for the signing AID
• Algorithm mismatches: Derivation code doesn't match expected algorithm

Performance Considerations

For production systems:

• Cache parsed cigar primitives to avoid redundant parsing
• Batch signature verifications when processing multiple messages
• Use binary domain encoding for network transmission efficiency
• Consider hardware acceleration for Ed25519 operations

Security Implementation

Critical security practices:

• Never expose Signer primitives outside secure boundaries
• Validate the entire message structure, not just the signature
• Implement proper nonce handling to prevent replay attacks
• Use constant-time comparison for signature verification results
• Protect against timing attacks in verification code paths