CRYPTO-GOV-01 — Politique de choix des algorithmes cryptographiques¶
Statut : Définitif Version : 1.0 Date : 2026-01-01 Auteur : Équipe Architecture ProbatioVault
1. Objectif¶
Ce document établit la gouvernance cryptographique officielle de ProbatioVault.
Principe directeur :
Chaque primitive cryptographique est choisie en fonction de la fonction probatoire qu'elle sert.
ProbatioVault n'est pas "un système de signature unique", mais un système de preuves à couches cryptographiques spécialisées.
2. Cartographie crypto officielle (DÉFINITIVE)¶
| Domaine | User Story | Algorithme | Rôle | Statut |
|---|---|---|---|---|
| Horodatage probatoire qualifié | PD-39 | ECDSA P-384 + SHA-384 | Signature du scellement batch (Merkle root) et attestations NTS | Définitif |
| Preuve interne / événements / dossiers | PD-40 | EdDSA Ed25519 | Re-signature, rotation, preuve composite | Définitif |
| Audit interne HSM | (hors US dédiée) | ECDSA P-384 | Signature des journaux d'audit HSM | Acceptable |
| PD-40 (INTERIM) | — | Mesure transitoire | Temporaire, non normatif |
3. Justifications par domaine¶
3.1. PD-39 : Horodatage probatoire qualifié (ECDSA P-384)¶
Algorithme : ECDSA P-384 (secp384r1) + SHA-384 Niveau de sécurité : ~192 bits
Pourquoi P-384 pour PD-39 ?¶
| Critère | Justification |
|---|---|
| Sécurité long terme | ~192 bits de sécurité, supérieur à Ed25519 (~128 bits). Adapté à des preuves à horizon 20–30 ans. |
| Conformité eIDAS / QTSA | ECDSA P-384 parfaitement accepté dans les chaînes QTSA (Qualified Timestamp Authority). Courbe classique, bien comprise par les auditeurs. |
| Réalité HSM | Support natif et robuste via PKCS#11. AWS CloudHSM : P-384 = chemin sans risque. Ed25519 encore parfois moins mature côté HSM/QTSA. |
| RFC 3161 | Standard d'horodatage RFC 3161 compatible ECDSA P-384. |
| Batch sealing | Signature du Merkle root des timestamps batch (cf. PD-39 spec). |
| NTS attestations | Signature des attestations d'horloge NTS (Network Time Security). |
Conclusion : PD-39 est cryptographiquement conservateur, ce qui est une qualité pour l'horodatage qualifié.
3.2. PD-40 : Preuve interne / rotation (Ed25519)¶
Algorithme : EdDSA Ed25519 Niveau de sécurité : ~128 bits (suffisant pour preuve interne opérationnelle)
Pourquoi Ed25519 pour PD-40 ?¶
| Critère | Ed25519 | ECDSA P-384 | Verdict |
|---|---|---|---|
| Performance | ✅ Excellente (~0.07ms/signature) | ❌ Plus lourd (~1.5ms/signature) | Ed25519 |
| Déterminisme | ✅ Natif (pas de RNG) | ❌ Dépend RNG | Ed25519 |
| Multi-signature additive | ✅ Très simple (append-only) | ⚠️ Plus complexe | Ed25519 |
| Vérification massive | ✅ Rapide | ❌ Plus coûteuse | Ed25519 |
| Dossiers volumineux | ✅ Optimal (64 bytes/sig) | ❌ Pénalisant (96 bytes/sig) | Ed25519 |
Cas d'usage PD-40 : - Rotation de clés HSM avec re-signature de 100,000+ événements - Preuve composite multi-signature (signatures additives) - Merkle proofs pour événements - Vérification fréquente par clients
Impact performance rotation : - P-384 : ~150 secondes pour 100k événements - Ed25519 : ~7 secondes pour 100k événements - Gain : 20x plus rapide
Conclusion : PD-40 n'est pas un horodatage qualifié, c'est de la preuve composite scalable. Ed25519 est le bon outil pour ce job.
3.3. Audit interne HSM (ECDSA P-384)¶
Algorithme : ECDSA P-384 + SHA-384 Statut : Acceptable (hors user story dédiée)
Justification : - Logs d'audit HSM signés avec même clé que PD-39 - Cohérence avec infrastructure TSA - Acceptable car volume faible (pas de contrainte performance)
4. Règles de gouvernance¶
4.1. Interdictions strictes¶
❌ Interdiction de mélange implicite : - PD-39 NE PEUT PAS utiliser Ed25519 (risque réglementaire eIDAS) - PD-40 NE DOIT PAS basculer vers P-384 (impact performance inacceptable)
❌ Interdiction d'harmonisation par le bas : - Ne pas "choisir un algo unique pour tout" - Chaque domaine probatoire a ses contraintes propres
❌ Interdiction de rétro-adaptation : - PD-40 ne doit pas être assouppli pour s'adapter à l'existant P-384
4.2. Évolution vers cryptographie post-quantique (PQC)¶
Stratégie différenciée (préparation future) :
| Domaine | Migration PQC cible |
|---|---|
| PD-39 (TSA) | Dilithium-5 ou SPHINCS+ (192+ bits, NIST PQC) |
| PD-40 (rotation) | Dilithium-3 ou Ed25519 hybride (128 bits suffisant) |
Principe : La migration PQC sera différenciée selon les niveaux de sécurité requis.
5. État transitoire (PD-40 INTERIM)¶
Situation actuelle : - PD-40 utilise temporairement ECDSA P-384 en attendant implémentation Ed25519 - Cet état est documenté dans TODO-IMPLEMENTATION.md
Statut : NON NORMATIF (mesure transitoire uniquement)
Action requise : Implémenter support Ed25519 dans HsmService (cf. PD-40 TODO)
6. Réponse pour audit / comité technique¶
Question : "Pourquoi deux algorithmes différents (P-384 et Ed25519) dans ProbatioVault ?"
Réponse officielle :
PD-39 utilise ECDSA P-384 de manière volontaire et définitive pour les fonctions d'horodatage qualifié (RFC 3161, NTS), afin d'atteindre ~192 bits de sécurité et une compatibilité maximale avec les QTSA et HSM.
PD-40 couvre un périmètre distinct (preuve interne, rotation, multi-signature) et impose Ed25519 pour des raisons de déterminisme, performance et vérification massive.
Il n'y a pas de contradiction : les algorithmes sont choisis par fonction probatoire, conformément à la politique cryptographique du système.
7. Références¶
- PD-39 Specification (TSA RFC 3161)
- PD-40 Specification (HSM Rotation)
- PD-40 TODO Implementation
- RFC 3161 (Internet X.509 Public Key Infrastructure Time-Stamp Protocol)
- NIST FIPS 186-4 (Digital Signature Standard - ECDSA)
- RFC 8032 (Edwards-Curve Digital Signature Algorithm - EdDSA)
- eIDAS Regulation (EU) 910/2014
8. Historique¶
| Version | Date | Auteur | Changements |
|---|---|---|---|
| 1.0 | 2026-01-01 | Architecture ProbatioVault | Création initiale - Formalisation gouvernance crypto |