Systèmes cryptographiques · Egothor
ZeroEcho
Un toolkit Java modulaire pour construire des workflows cryptographiques et PKI exigeant des choix algorithmiques explicites, des frontières de clés contrôlées et une trajectoire d’évolution de la cryptographie classique vers des déploiements post-quantiques et hybrides.
La cryptographie comme architecture, pas comme sac d’algorithmes
ZeroEcho est parti d’un besoin pratique : rendre la cryptographie moderne utilisable dans des workflows applicatifs répétables sans cacher les décisions critiques dans un état global ou une commande monolithique. Le résultat est un toolkit en couches où algorithmes, clés, contenu protégé, services PKI et intégration applicative possèdent des frontières explicites.
- L’agilité algorithmique signifie des choix explicites, pas des defaults cachés.
- Les frontières de clés comptent autant que le choix des primitives.
- La PKI appartient à l’architecture, pas à côté d’elle.
- La migration hybride est traitée comme une véritable phase d’ingénierie.
Agilité algorithmique sans prétendre que la migration est instantanée
La transition post-quantique n’est pas un drapeau que chaque système peut basculer simultanément. Écosystèmes de certificats, protocoles, matériel et contreparties évoluent à des rythmes différents. ZeroEcho conserve donc les options classiques, post-quantiques et hybrides dans le même modèle d’ingénierie au lieu de traiter une famille comme un projet annexe temporaire.
Interopérabilité aujourd’hui
RSA, ECDSA, Ed25519/Ed448 et les modes symétriques établis restent disponibles pour les protocoles et contreparties qui dépendent d’une cryptographie classique mature.
Migrer là où cela convient
ML-KEM et les familles de signatures post-quantiques peuvent être sélectionnés via le même toolkit plutôt que d’exiger une pile applicative sans rapport.
Faire le pont pendant la transition
Les constructions hybrides soutiennent les déploiements qui recherchent de la résilience entre familles d’algorithmes pendant que l’interopérabilité et les politiques rattrapent leur retard.
Le matériau de clé reste derrière une frontière
Un principe récurrent est que les services PKI de haut niveau ne devraient pas transporter des clés privées brutes dans leurs API. Les clés sont adressées par des références stables ; la signature et la récupération de clés publiques passent par une frontière de matériau cryptographique. La couche PKI peut ainsi rester concentrée sur certificats, profils, politique et statut au lieu de devenir un second key store.
Références de clés explicites
Des identifiants stables permettent aux services de demander des opérations cryptographiques sans traiter les clés privées comme des données applicatives ordinaires.
Opérations sensibles au cycle de vie
Les signatures longues ou externes sont modélisées avec état explicite et idempotence plutôt que de supposer que chaque appel fournisseur termine synchroniquement.
Frontières de contenu validées
Le contenu cryptographique persistant est lié à des contrôles d’intégrité et des références contrôlées afin que reprise et continuation restent auditables.
Identités algorithmiques versionnées
Les choix d’algorithmes et d’interopérabilité sont représentés explicitement : les defaults déployés peuvent rester stables tandis que de nouvelles combinaisons sont introduites délibérément.
Configuration déterministe
La configuration est pensée pour être inspectable et reproductible plutôt que de dépendre d’un état fournisseur mutable à l’échelle du processus.
Livraison scriptable
La CLI expose les mêmes capacités fondamentales aux workflows automatisés et offline, pas une implémentation cryptographique séparée.
La PKI fait partie du système actuel
La couche PKI est organisée autour de contrats de services plutôt que d’un objet CA universel. Demandes de certificats, émission, révocation, profils, politique, publication, objets de statut, sauvegarde/import-export et inventaire d’identifiants sont séparés afin d’évoluer indépendamment tout en partageant les mêmes frontières de stockage et de clés.
L’objectif est volontairement plus exigeant que « générer un certificat ». Une PKI de production doit pouvoir répondre à ce qui a été demandé, autorisé, quelle clé a prouvé la possession, quel profil a été appliqué, ce qui a été persisté et comment le statut peut être reconstruit après redémarrage.
Workflows de données résilients
ZeroEcho conserve aussi son orientation opérationnelle initiale : protection multi-destinataires, chiffrement et signature scriptables, et workflows qui ne supposent pas une connectivité permanente. Le transport offline ou indirect est traité comme une condition de déploiement légitime, tandis que les techniques expérimentales d’export covert restent isolées du cœur cryptographique et PKI.