Cryptographic systems · Egothor

ZeroEcho

A modular Java toolkit for building cryptographic and PKI workflows that need explicit algorithm choices, controlled key boundaries and an evolutionary path from classical cryptography to post-quantum and hybrid deployments.

PQCNIST-era algorithmsML-KEM plus post-quantum signature families in the active algorithm inventory
Hybridmigration modelclassical and post-quantum mechanisms can coexist where interoperability requires it
PKIservice layerissuance, revocation, status and publication belong inside the architecture
Offlineoperational workflowsdesigned for scriptable and constrained delivery patterns as well as connected systems

Cryptography as an architecture, not a bag of algorithms

ZeroEcho started from a practical requirement: make modern cryptography usable in repeatable application workflows without hiding critical decisions in global state or a monolithic command. The result is a layered toolkit in which algorithms, keys, protected content, PKI services and application integration have explicit boundaries.

Algorithmsclassical · PQC · hybrid→ Key boundaryreferences, not loose private material→ Crypto workflowsencrypt · sign · verify→ PKI servicesissue · revoke · status→ ApplicationsCLI · automation · integration

Algorithm agility without pretending migration is instantaneous

Post-quantum transition is not a flag that every system can flip at once. Certificate ecosystems, protocols, hardware and counterparties evolve at different speeds. ZeroEcho therefore keeps classical, post-quantum and hybrid options in the same engineering model instead of treating one family as a temporary side project.

CLASSICAL

Interoperability today

RSA, ECDSA, Ed25519/Ed448 and established symmetric modes remain available for protocols and counterparties that depend on mature classical cryptography.

POST-QUANTUM

Migration where it fits

ML-KEM and post-quantum signature families can be selected through the same broader toolkit rather than requiring an unrelated application stack.

HYBRID

Bridge the transition

Hybrid constructions support deployments that want resilience across algorithm families while interoperability and policy catch up.

Key material stays behind a boundary

A recurring design principle is that higher PKI services should not need to carry raw private keys through their APIs. Keys are addressed through stable references; signing and public-key retrieval happen through a key-material boundary. This keeps the PKI layer focused on certificates, profiles, policy and status rather than turning it into a second key store.

Explicit key references

Stable key identifiers let services request cryptographic operations without treating private key material as ordinary application data.

Lifecycle-aware operations

Long-running or external signing operations are modeled with explicit state and idempotency instead of assuming every provider call completes synchronously.

Validated content boundaries

Persisted cryptographic content is tied to integrity checks and controlled references so recovery and continuation remain auditable.

Versioned algorithm identities

Algorithm and interoperability choices are represented explicitly so deployed defaults can remain stable while additional combinations are introduced deliberately.

Deterministic configuration

Configuration is intended to be inspectable and reproducible rather than depending on process-wide mutable provider state.

Scriptable delivery

The CLI exposes the same underlying capabilities to automated and offline workflows, not a separate cryptographic implementation.

PKI is part of the current system

The PKI layer is structured around service contracts rather than one all-purpose CA object. Certificate requests, issuance, revocation, profiles, policy, publication, status objects, backup/import-export and credential inventory are separated so they can evolve independently while sharing the same storage and key boundaries.

Certificate lifecyclerequests · proof of possession · issuance · revocation
Policy & profilesapproved algorithm/profile combinations · validity · metadata
Status servicesOCSP-style certificate status · time-stamp service integration
Publicationcertificate/status artifacts and durable content references
Key operationsprivate material remains in a key-material provider boundary
Recoverypersistence, backup and restart-safe continuation of durable operations

The goal is deliberately more demanding than “generate a certificate.” A production PKI has to answer what was requested, what was authorized, which key proved possession, which profile was applied, what was persisted and how status can be reconstructed after restart.

Resilient data workflows

ZeroEcho also keeps its original operational focus: multi-recipient protection, scriptable encryption and signing, and workflows that do not assume permanent connectivity. Offline or indirect transport is treated as a legitimate deployment condition, while experimental covert-export techniques remain isolated from the core cryptographic and PKI architecture.

Cryptographic deployment is version-specific. Algorithms, provider capabilities and protocol interoperability change over time. This portfolio page explains the engineering model; the repository and generated JavaDoc remain the source of truth for exact APIs and algorithm availability in a given release.

Project resources