Kryptographische Systeme · Egothor
ZeroEcho
Ein modulares Java-Toolkit zum Aufbau kryptographischer und PKI-Workflows, die explizite Algorithmusentscheidungen, kontrollierte Schlüsselgrenzen und einen Evolutionspfad von klassischer Kryptographie zu Post-Quantum- und Hybrid-Deployments benötigen.
Kryptographie als Architektur, nicht als Sammlung von Algorithmen
ZeroEcho entstand aus einer praktischen Anforderung: moderne Kryptographie in wiederholbaren Anwendungsworkflows nutzbar machen, ohne kritische Entscheidungen in globalem Zustand oder einem monolithischen Kommando zu verstecken. Das Ergebnis ist ein geschichtetes Toolkit, in dem Algorithmen, Schlüssel, geschützte Inhalte, PKI-Services und Anwendungsintegration explizite Grenzen besitzen.
- Algorithm Agility bedeutet explizite Entscheidungen, nicht versteckte Defaults.
- Schlüsselgrenzen sind genauso wichtig wie die Auswahl der Primitive.
- PKI gehört in die Architektur, nicht daneben.
- Hybride Migration wird als reale Engineering-Phase behandelt.
Algorithm Agility ohne die Illusion einer sofortigen Migration
Der Post-Quantum-Übergang ist kein Schalter, den jedes System gleichzeitig umlegen kann. Zertifikatsökosysteme, Protokolle, Hardware und Gegenstellen entwickeln sich unterschiedlich schnell. ZeroEcho hält daher klassische, Post-Quantum- und hybride Optionen im selben Engineering-Modell, statt eine Familie als vorübergehendes Nebenprojekt zu behandeln.
Interoperabilität heute
RSA, ECDSA, Ed25519/Ed448 und etablierte symmetrische Modi bleiben für Protokolle und Gegenstellen verfügbar, die auf ausgereifte klassische Kryptographie angewiesen sind.
Migration dort, wo sie passt
ML-KEM und Post-Quantum-Signaturfamilien können über dasselbe Toolkit gewählt werden, ohne einen unabhängigen zweiten Application Stack zu benötigen.
Die Übergangsphase überbrücken
Hybride Konstruktionen unterstützen Deployments, die Resilienz über Algorithmusfamilien hinweg wünschen, während Interoperabilität und Policy nachziehen.
Schlüsselmaterial bleibt hinter einer Grenze
Ein wiederkehrendes Designprinzip ist, dass höhere PKI-Services keine rohen privaten Schlüssel durch ihre APIs transportieren sollten. Schlüssel werden über stabile Referenzen adressiert; Signatur und Abruf öffentlicher Schlüssel erfolgen über eine Key-Material-Grenze. Dadurch kann sich die PKI-Schicht auf Zertifikate, Profile, Policy und Status konzentrieren, statt selbst zu einem zweiten Key Store zu werden.
Explizite Schlüsselreferenzen
Stabile Schlüssel-IDs erlauben Services kryptographische Operationen anzufordern, ohne privates Schlüsselmaterial wie gewöhnliche Anwendungsdaten zu behandeln.
Lifecycle-bewusste Operationen
Länger laufende oder externe Signaturoperationen werden mit explizitem Zustand und Idempotenz modelliert, statt anzunehmen, dass jeder Provider-Call synchron endet.
Validierte Content-Grenzen
Persistierte kryptographische Inhalte sind an Integritätsprüfungen und kontrollierte Referenzen gebunden, damit Recovery und Fortsetzung auditierbar bleiben.
Versionierte Algorithmusidentitäten
Algorithmus- und Interoperabilitätsentscheidungen werden explizit repräsentiert, sodass deployte Defaults stabil bleiben können, während neue Kombinationen bewusst eingeführt werden.
Deterministische Konfiguration
Konfiguration soll inspizierbar und reproduzierbar sein, statt von prozessweitem mutablem Provider-State abzuhängen.
Skriptbare Delivery
Die CLI stellt automatisierten und Offline-Workflows dieselben zugrunde liegenden Fähigkeiten bereit, nicht eine separate Kryptographieimplementierung.
PKI ist Teil des aktuellen Systems
Die PKI-Schicht ist um Service-Verträge statt um ein universelles CA-Objekt strukturiert. Certificate Requests, Issuance, Revocation, Profile, Policy, Publication, Statusobjekte, Backup/Import-Export und Credential Inventory sind getrennt, damit sie unabhängig weiterentwickelt werden können und dennoch dieselben Storage- und Schlüsselgrenzen teilen.
Das Ziel ist bewusst anspruchsvoller als „ein Zertifikat generieren“. Eine Produktions-PKI muss beantworten können, was beantragt und autorisiert wurde, welcher Schlüssel Besitz nachwies, welches Profil angewandt wurde, was persistiert wurde und wie Status nach einem Neustart rekonstruiert werden kann.
Resiliente Datenworkflows
ZeroEcho behält auch seinen ursprünglichen betrieblichen Fokus: Multi-Recipient-Schutz, skriptbare Verschlüsselung und Signatur sowie Workflows, die keine permanente Konnektivität voraussetzen. Offline- oder indirekter Transport gilt als legitime Deployment-Bedingung; experimentelle Covert-Export-Techniken bleiben vom kryptographischen und PKI-Kern isoliert.