• .qb64() - qualified base-64 string representation
• .qb64b() - qualified base-64 representation as bytes
• .qb2() - qualified base-2 binary representation
• .code() - derivation code indicating hash algorithm
• .raw() - raw hash bytes without qualification

Verfer - Represents a public key used for signature verification. It provides methods to verify signatures on data and can be derived from a Signer. The Verfer primitive is essential for validating key event signatures in KEL processing.

Signer - Represents a private key with signing capabilities. Can generate both indexed signatures (Siger) for multi-key scenarios and unindexed signatures (Cigar) for single-key use cases. This primitive is critical for controller operations when creating signed events.

Siger - An indexed signature attachment used when signing with multi-key autonomic identifiers. The index indicates which of multiple public keys was used to generate the signature, critical for KERI's multi-sig support and threshold signature schemes.

Cigar - An unindexed signature for single-key signing scenarios where no index is needed. Used in contexts where the signing key is unambiguous.

Salter - Represents a cryptographic seed that can deterministically generate Signer instances through key stretching, enabling hierarchical key derivation.

Qualification System

All primitives support CESR's qualification scheme, where cryptographic material is prefixed with a derivation code that describes its type and algorithm. For example:

• DKxy2sgzfplyr-tgwIxS19f2OchFHtLwPWD3v4oYimBx - prefix D indicates a transferable Ed25519 public key
• ELEjyRTtmfyp4VpTBTkv_b6KONMS1V8-EW-aGJ5P_QMo - prefix E indicates a Blake3-256 digest

This qualification enables self-framing streams where parsers can identify and extract primitives without pre-negotiated schemas, a key feature for KERI's composability.

Cryptographic Algorithm Support

The library supports nine hash algorithms across three families:

Blake3: 256-bit and 512-bit variants (recommended for most applications due to performance and security)

Blake2: Blake2b-256 and Blake2b-512, Blake2s-256 variants

SHA: SHA3-256, SHA3-512, SHA2-256, SHA2-512 for compatibility with existing systems

For digital signatures, cesride supports:

Ed25519: Edwards-curve Digital Signature Algorithm, the primary signing algorithm in KERI

ECDSA secp256k1: For Bitcoin/Ethereum compatibility scenarios

The library provides both transferable and non-transferable key derivation codes, enabling support for both persistent identifiers (where keys can be rotated) and ephemeral identifiers (where keys cannot be rotated).

Common Methods Across Primitives

Each primitive type implements a consistent set of methods:

• .qb64() - Returns qualified base-64 representation as a string
• .qb64b() - Returns qualified base-64 representation as bytes
• .qb2() - Returns qualified base-2 binary representation
• .code() - Returns the derivation code indicating cryptographic algorithm
• .raw() - Returns raw cryptographic material without qualification

This consistent interface enables generic handling of cryptographic primitives across the KERI protocol stack.

Stream Parsing Architecture

cesride works in conjunction with Parside, the stream parsing component. The division of responsibilities is:

• cesride: Parses individual CESR primitives
• Parside: Parses group codes and manages chunk-delimited stream processing

This modular design leverages CESR's self-framing property, allowing parsers to dispatch different parts of the stream to appropriate parsing entities based on the strip parameter.

The sniffer component detects stream format types:

• CESR binary
• CESR text
• JSON
• CBOR
• MessagePack

For non-CESR formats, the parser uses regex to find the version string inside the data structure, extracts the length, and resumes sniffing after processing that section.

WebAssembly Support

cesride includes a WASM FFI layer that enables JavaScript/TypeScript applications to utilize cesride's CESR parsing capabilities and cryptographic primitives across multiple JavaScript runtime environments through WebAssembly bindings.

Three build targets are supported:

1. Default (Webpack bundler): wasm-pack build - outputs modules optimized for webpack bundling
2. NodeJS: wasm-pack build --target=nodejs - generates modules for direct NodeJS consumption
3. Web Browser: wasm-pack build --target=web - creates modules for direct browser usage without bundlers

Demo applications are provided for both NodeJS (demo/node/) and browser (demo/web/) environments.

Installation & Setup

Prerequisites

For WASM builds, the official Rust WASM toolchain is required:

cargo install wasm-pack

Build Instructions

The standard Rust build process applies:

cargo build --release

For WebAssembly targets:

# Default webpack target
wasm-pack build

# NodeJS target
wasm-pack build --target=nodejs

# Browser target
wasm-pack build --target=web

Demo Applications

Two demonstration implementations are provided:

NodeJS Demo (located in demo/node/):

cd demo/node
yarn install
yarn start

Browser Demo (located in demo/web/):

cd demo/web
yarn install
yarn serve
# Access via http://localhost:8080

Usage & API

Basic Primitive Operations

While specific API documentation is not provided in the source documents, the common methods pattern indicates typical usage:

// Creating a Diger from data
let data = b"example data";
let diger = Diger::new(data, DigestAlgorithm::Blake3_256);

// Getting qualified representations
let qb64_string = diger.qb64();  // "ELEjyRTtmfyp4VpTBTkv_b6KONMS1V8-EW-aGJ5P_QMo"
let qb64_bytes = diger.qb64b();  // Bytes representation
let qb2_binary = diger.qb2();    // Binary representation
let code = diger.code();         // "E" for Blake3-256
let raw = diger.raw();           // Raw hash bytes

// Verification
let is_valid = diger.verify(data);

Key Generation and Signing

// Creating a Salter (seed)
let salter = Salter::new();

// Generating a Signer from seed
let signer = salter.generate_signer();

// Creating signatures
let data = b"message to sign";
let cigar = signer.sign(data);  // Unindexed signature
let siger = signer.sign_indexed(data, 0);  // Indexed signature with index 0

// Getting corresponding Verfer
let verfer = signer.verfer();

// Verification
let is_valid = verfer.verify(data, &cigar);

Stream Processing Integration

The cesride primitives integrate with Parside for stream processing:

• Parside handles count codes at the beginning of streams
• cesride parses individual primitives within groups
• The version code determines which CESR table to load
• Recursive parsing handles nested group structures

Related Implementations

Python Implementation

KERIpy - The reference implementation in Python, from which cesride is ported. KERIpy provides 100% compliance with KERI, ACDC, and CESR specifications and serves as the authoritative implementation.

Other Rust Implementations

keride - A Rust library for Key Event Receipt Infrastructure that includes CESR, signing, prefixing, pathing, and parsing capabilities. While cesride focuses on primitives, keride provides higher-level KERI protocol operations.

TypeScript/JavaScript Implementations

signify-ts - TypeScript edge agent library that can consume cesride's WASM bindings for client-side KERI operations with minimal cryptographic overhead.

Integration Points

cesride serves as a foundational layer that can be consumed by:

• KERIA - KERI Agent infrastructure (though primarily uses KERIpy)
• Web applications - Via WASM bindings for browser-based KERI operations
• NodeJS services - Via WASM NodeJS target for server-side JavaScript
• Native Rust applications - Direct library integration for performance-critical applications

Implementation Notes

Licensing and Governance

cesride is licensed under Apache 2.0, which differs from some other Rust KERI implementations. The licensing discussion in the KERI community (captured in December 2022 - August 2023 Slack discussions) reveals important context:

• cesrox and keriox (from Human Colossus Foundation) use EUPL v1.2 (copyleft license)
• cesride uses Apache 2.0 (permissive license)
• The WebOfTrust organization (Samuel Smith's leadership) standardizes on Apache 2.0
• This licensing difference has implications for contribution policies and ecosystem integration

Developers should be aware that mixing EUPL and Apache 2.0 code may have legal implications depending on jurisdiction and usage patterns.

Development Status

As of the source documents (September 2020), cesride is described as "currently under active development." The implementation provides approximately 90% CESR 1.0 compliance according to the KERI ecosystem overview, though some sources indicate it may be "currently inactive."

Developers should verify the current maintenance status before adopting cesride for production use.

Performance Considerations

Rust implementations like cesride offer significant performance advantages over Python implementations:

• Zero-cost abstractions - Rust's ownership system enables memory safety without garbage collection overhead
• Native compilation - Direct compilation to machine code rather than interpreted execution
• WASM efficiency - WebAssembly bindings provide near-native performance in browser environments

These characteristics make cesride particularly suitable for:

• High-throughput stream processing
• Resource-constrained environments (embedded systems, mobile devices)
• Browser-based applications requiring cryptographic operations

Compatibility with KERIpy

The source documents explicitly state that cesride is "ported from KERIpy" and "maintains compatibility with its terminology and design decisions." This means:

• Primitive naming conventions match KERIpy
• Derivation codes are interoperable
• Qualified representations can be exchanged between implementations
• Stream formats are compatible

However, developers should test interoperability for their specific use cases, as implementation details may diverge over time.

Version Management

The parsing architecture requires careful version management:

• Parside must start with a default CESR version
• Version count codes change the active version
• Version codes must appear at the top level
• The version determines which code table to load

This design enables forward compatibility as CESR specifications evolve.

Cold Start Behavior

The parser maintains a default version count code to handle scenarios where:

• The stream does not begin with an explicit version code
• Processing resumes after a cold restart
• Count code interpretation must proceed without explicit version context

This robustness is critical for production systems that may experience interruptions.

Dynamic Code Table Support

The architecture supports dynamically loaded code tables, allowing cesride to handle different versions and extensions of CESR specifications without requiring parser modification. This extensibility is important for long-term protocol evolution.

Ecosystem Context

cesride is part of the broader KERI suite of technologies, which includes:

• KERI - Key Event Receipt Infrastructure protocol
• ACDC - Authentic Chained Data Containers for verifiable credentials
• CESR - Composable Event Streaming Representation encoding
• OOBI - Out-Of-Band Introduction for discovery
• IPEX - Issuance and Presentation Exchange protocol

The KERI community coordinates through:

• Discord server - Real-time collaboration
• Bi-weekly implementors calls - Tuesdays at 10 AM EDT/EST
• Trust over IP Foundation - Specification governance
• WebOfTrust GitHub organization - Code repositories

Developers working with cesride should engage with this community for support, updates, and contribution opportunities.

Ecosystem Coordination

Developers should:

• Engage with the KERI community via Discord and bi-weekly calls
• Follow Trust over IP Foundation specification updates
• Monitor the WebOfTrust GitHub organization for changes
• Contribute back improvements and bug fixes

Security Considerations

When using cesride for cryptographic operations:

• Verify that the implementation uses secure random number generation
• Ensure proper key management practices (especially for Salter/Signer)
• Validate that hash algorithms meet security requirements for your use case
• Test signature verification thoroughly before production deployment
• Consider using Hardware Security Modules (HSMs) for high-value key material

Testing and Validation

Before production use:

• Run the provided demo applications to verify correct installation
• Test interoperability with other KERI implementations
• Validate that qualified representations match expected formats
• Verify stream parsing handles edge cases correctly
• Test cold start and version transition scenarios