Votre checklist d’action
- 01
Inventorier la cryptographie
Identifiez protocoles, certificats, signatures, bibliothèques, matériels et propriétaires. Incluez les dépendances cachées des logiciels et services managés. Ne limitez pas l’inventaire au trafic HTTPS. Examinez signatures de mises à jour, échanges entre services, sauvegardes chiffrées, équipements embarqués et accès distants. Notez les versions et les interfaces permettant un changement d’algorithme.
- 02
Classer les durées de sensibilité
Repérez les données qui doivent rester confidentielles longtemps et les systèmes difficiles à remplacer. Documentez les hypothèses sans prédire une date certaine d’arrivée d’un ordinateur quantique pertinent. Distinguez la durée de conservation d’un fichier de la durée pendant laquelle son contenu doit rester confidentiel. Un système à cycle de vie long peut demander une préparation plus précoce qu’une application fréquemment renouvelée. Rendez ces hypothèses explicites.
- 03
Suivre les standards originaux
Consultez les publications du NIST et les recommandations de votre autorité nationale. Distinguez les standards finalisés, les projets et les offres commerciales. Pour chaque choix, enregistrez l’organisme, la référence, la version et le statut du document. Vérifiez les profils d’usage applicables au contexte. Une compatibilité annoncée dans une présentation commerciale ne vaut pas un support documenté en production.
- 04
Interroger les fournisseurs
Demandez une feuille de route de migration, la compatibilité des clients et les limites matérielles. Vérifiez les engagements contractuels et la disponibilité réelle des fonctions annoncées. Demandez quel composant réalise réellement l’opération cryptographique, quelles versions de clients sont nécessaires et comment revenir à un état fonctionnel. Reliez la réponse à une dépendance de votre inventaire plutôt qu’à une déclaration générale de conformité.
- 05
Tester sans improviser de cryptographie
Utilisez des implémentations maintenues dans un environnement de test. Mesurez interopérabilité, taille des messages, performances et mécanismes de retour arrière. Définissez une transaction de référence puis comparez réussite, erreurs, temps et tailles sur des clients représentatifs. Testez les intermédiaires réseau et les équipements contraints. Conservez la configuration exacte afin de distinguer incompatibilité et défaut de mesure.
- 06
Construire une migration progressive
Priorisez les services, définissez des critères d’acceptation et conservez des preuves de test. Préparez la crypto-agilité pour pouvoir changer d’algorithme sans refondre tout le système. Planifiez un pilote réversible, une revue des résultats et une progression par dépendance. Définissez qui peut autoriser la bascule et qui surveille les échecs. Une migration est acceptée lorsque les usages critiques restent vérifiés dans leur configuration cible.
Exemple pédagogique : un prestataire propose une évolution cryptographique. Demandez quels échanges et bibliothèques changent, quels équipements restent compatibles et comment revenir à la configuration précédente. Le test compare établissement de connexion, erreurs, performance et capacité de récupération. Une mention « post-quantique » ne constitue pas à elle seule une preuve de bonne intégration du système complet.
Références : données, usages et limites
Documentation consultée le .
| Source et objet | Donnée ou repère vérifié | Comment l’utiliser | Limite à conserver |
|---|---|---|---|
| SPDX · Specifications Décrire les composants et informations d’une nomenclature logicielle. |
La page officielle distingue SPDX 3.0 de versions antérieures comme 2.3. La version du document conditionne le schéma et les outils compatibles. | Demandez le format, la version, le périmètre de construction et les identifiants des composants. Comparez la nomenclature à l’artefact effectivement livré. | Une nomenclature ne démontre pas à elle seule l’absence de vulnérabilité, la complétude des dépendances ou la conformité de toutes les licences. |
| OWASP · CycloneDX Échanger des nomenclatures et informations de chaîne d’approvisionnement. |
La spécification 1.7 est datée du 21 octobre 2025 sur la page officielle, qui documente JSON, XML et Protobuf. | Vérifiez la version, les références de composants et les liens de dépendance. Conservez la relation entre la nomenclature, la construction et le produit déployé. | Un changement de format ne corrige pas des composants manquants. Une nomenclature descriptive et une analyse d’impact de vulnérabilité répondent à des questions différentes. |
| NIST · Post-quantum cryptography Identifier les standards utiles à une transition cryptographique. |
Le NIST distingue FIPS 203 pour ML-KEM, FIPS 204 pour ML-DSA et FIPS 205 pour SLH-DSA. Encapsulation de clé et signature sont des fonctions différentes. | Inventoriez protocoles, bibliothèques, clés et dépendances. Demandez les versions réellement implémentées et testez interopérabilité, performance et retour arrière. Comparer les paramètres post-quantiques et estimer leurs volumes → |
La présence d’un algorithme standardisé ne démontre pas la sécurité de son intégration complète ni une échéance universelle de migration. |
Cryptographie post-quantique : comparer avant de migrer
ML-KEM établit un secret partagé ; ML-DSA et SLH-DSA signent des données. Ces fonctions répondent à des besoins différents. Les 18 jeux de paramètres ci-dessous proviennent des trois standards FIPS finaux publiés le 13 août 2024. Ils permettent de préparer un inventaire et des essais de capacité, sans déduire la sécurité d’un système du seul nom de son algorithme.
Données et pages de statut vérifiées le .
ML-KEM · Établir un secret
- Le destinataire publie sa clé d’encapsulation.
- L’émetteur produit un chiffré et un secret partagé, puis transmet le chiffré.
- Le destinataire retrouve le secret avec sa clé de décapsulation.
L’authentification du pair et l’usage du secret relèvent du protocole complet.
ML-DSA / SLH-DSA · Signer
- Le signataire protège sa clé privée et distribue sa clé publique.
- Il signe les données et transmet les données avec leur signature.
- Le vérificateur contrôle la signature avec la clé publique de confiance.
La signature seule ne chiffre pas le contenu signé.
Pour ML-KEM, les clés publique et privée servent respectivement à l’encapsulation et à la décapsulation ; la cinquième colonne est le chiffré. Pour les deux familles DSA, les clés servent à la vérification et à la signature ; la cinquième colonne est la signature. Le tiret signifie « sans objet ». Les catégories NIST ne sont ni des notes de qualité ni des tailles de clés en bits.
| Jeu de paramètres / source | Catégorie NIST | Clé publique | Clé privée | Chiffré KEM / signature | Secret partagé |
|---|---|---|---|---|---|
| ML-KEM-512FIPS 203 | 1 | 800 | 1 632 | 768 | 32 |
| ML-KEM-768FIPS 203 | 3 | 1 184 | 2 400 | 1 088 | 32 |
| ML-KEM-1024FIPS 203 | 5 | 1 568 | 3 168 | 1 568 | 32 |
| ML-DSA-44FIPS 204 | 2 | 1 312 | 2 560 | 2 420 | — |
| ML-DSA-65FIPS 204 | 3 | 1 952 | 4 032 | 3 309 | — |
| ML-DSA-87FIPS 204 | 5 | 2 592 | 4 896 | 4 627 | — |
| SLH-DSA-SHA2-128sFIPS 205 | 1 | 32 | 64 | 7 856 | — |
| SLH-DSA-SHA2-128fFIPS 205 | 1 | 32 | 64 | 17 088 | — |
| SLH-DSA-SHA2-192sFIPS 205 | 3 | 48 | 96 | 16 224 | — |
| SLH-DSA-SHA2-192fFIPS 205 | 3 | 48 | 96 | 35 664 | — |
| SLH-DSA-SHA2-256sFIPS 205 | 5 | 64 | 128 | 29 792 | — |
| SLH-DSA-SHA2-256fFIPS 205 | 5 | 64 | 128 | 49 856 | — |
| SLH-DSA-SHAKE-128sFIPS 205 | 1 | 32 | 64 | 7 856 | — |
| SLH-DSA-SHAKE-128fFIPS 205 | 1 | 32 | 64 | 17 088 | — |
| SLH-DSA-SHAKE-192sFIPS 205 | 3 | 48 | 96 | 16 224 | — |
| SLH-DSA-SHAKE-192fFIPS 205 | 3 | 48 | 96 | 35 664 | — |
| SLH-DSA-SHAKE-256sFIPS 205 | 5 | 64 | 128 | 29 792 | — |
| SLH-DSA-SHAKE-256fFIPS 205 | 5 | 64 | 128 | 49 856 | — |
Les tailles concernent les encodages bruts définis par les standards. Une clé privée stockée sous forme de graine peut occuper moins d’espace que l’encodage complet indiqué ici. Certificats, conteneurs, encodage Base64, en-têtes de protocole et protection du stockage ajoutent leurs propres octets. Pour SLH-DSA, « s » privilégie la compacité des signatures et « f » leur génération plus rapide ; les familles SHA2 et SHAKE partagent les tailles de chaque variante, pas la même instanciation de hachage.
Estimer un volume de données cryptographiques
Choisissez un jeu et un nombre d’objets. Le calcul additionne uniquement des tailles brutes publiques : un chiffré KEM ou une signature par objet, avec une clé publique transmise une seule fois ou répétée pour chaque objet. La clé privée et le secret partagé restent exclus du transfert modélisé.
Exemple chiffré pour préparer un essai
Pour 1 000 objets ML-KEM-768 et une clé publique par objet : 1 000 × (1 184 + 1 088) = 2 272 000 octets bruts. Avec une seule clé publique pour le lot : 1 184 + 1 000 × 1 088 = 1 089 184 octets. Il s’agit d’une hypothèse pédagogique de transport, pas d’une mesure d’un service ou d’un protocole.
Ce modèle de volume ne mesure ni durée de calcul, ni débit, ni latence TLS, ni sécurité. Le mode « une seule clé » suppose qu’un même destinataire ou vérificateur peut réutiliser cette clé selon le protocole retenu. Vérifiez cette hypothèse, la rotation des clés et les limites de taille sur votre environnement. Aucun contenu, aucune clé et aucune donnée saisie ne sont envoyés par cet outil.
Quelles preuves demander avant un pilote ?
| Usage à inventorier | Éléments à relever | Essai utile et condition de décision |
|---|---|---|
| Échanges et données confidentielles | Application, protocole, bibliothèque et version ; fonction d’établissement de clé ; durée de sensibilité des données ; équipements intermédiaires. | Rejouer les connexions sur une plateforme de test autorisée, relever erreurs et volumes, vérifier les pairs réellement compatibles et le retour à la configuration approuvée. |
| Signature de logiciels et mises à jour | Chaîne de construction, format signé, clés et vérificateurs embarqués ; capacité à renouveler la racine de confiance. | Vérifier un paquet valide puis un paquet altéré. Mesurer la taille finale du manifeste et confirmer que les anciens appareils disposent d’un chemin de mise à jour. |
| Certificats et identités techniques | Autorités, profils de certificats, algorithmes de signature, magasins de confiance et dépendances tierces. | Contrôler création, renouvellement et révocation dans les produits concernés. L’acceptation d’un algorithme dans une bibliothèque ne suffit pas à prouver celle du certificat complet. |
| Sauvegardes, archives et conservation | Formats, clés nécessaires à la restauration, responsabilités de garde et versions capables de relire les objets historiques. | Restaurer un échantillon ancien dans l’environnement cible ; conserver les éléments de vérification nécessaires. Une migration des connexions ne re-chiffre pas automatiquement les archives. |
Questions de décision
ML-KEM remplace-t-il une signature ?
Non. L’encapsulation sert à établir un secret partagé. La signature sert à vérifier l’intégrité et l’origine des données selon le mécanisme de confiance choisi. Un projet peut devoir faire évoluer ces deux fonctions séparément.
Le plus petit objet est-il le meilleur choix ?
La taille ne répond qu’à une contrainte de capacité. Le choix doit aussi tenir compte des exigences de sécurité, des implémentations maintenues, de la compatibilité et des résultats d’essais. Le comparateur ne classe pas les algorithmes.
Un produit « FIPS 203 » est-il automatiquement certifié ?
La référence à un standard décrit une spécification d’algorithme. Demandez séparément la preuve de conformité ou de validation annoncée, son périmètre exact, la version du module et la configuration évaluée.
Pourquoi consulter les pages de statut en plus du standard ?
Les pages NIST signalent les mises à jour potentielles : note du 17 novembre 2025 pour FIPS 203 et du 31 juillet 2026 pour FIPS 204 lors de cette consultation. Le fournisseur doit préciser les corrections prises en compte dans sa version.
Provenance des valeurs et limites de fraîcheur
Les liens mènent aux notices officielles et à leur historique. Tailles relevées dans les tables indiquées ; clés privées SLH-DSA calculées selon la règle 4n du §3.1. Périmètre limité aux jeux des FIPS 203–205 : ce tableau n’est pas un inventaire de tous les travaux post-quantiques, projets ou profils de protocoles.
- NIST FIPS 203 · ML-KEM · §8, tables 2–3; §8 security categories
Publication du standard : · Note de mise à jour potentielle : - NIST FIPS 204 · ML-DSA · §4, tables 1–2
Publication du standard : · Note de mise à jour potentielle : - NIST FIPS 205 · SLH-DSA · §11, table 2; §3.1: private key = 4n bytes
Publication du standard :
ETag, cache HTTP et modifications concurrentes
Trois preuves de cohérence pour une mise en production
La fraîcheur d’une lecture et l’isolation des utilisateurs doivent se vérifier sur les mêmes variantes que celles réellement servies.
- Tracer GET conditionnel → 304, puis modification de la ressource → 200.
- Faire passer le refus d’accès avant la condition ETag pour une ressource protégée.
- Tester l’ancienne version en écriture : 412 et absence de modification effective.
Explorer les comparaisons et le simulateur ETag →
Références relues le · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3
VEX et applicabilité produit
Demander une déclaration d’applicabilité reliée au produit livré
Un fournisseur peut fournir une SBOM et un document VEX sans que leur portée corresponde à votre build. Le contrôle consiste à relier ces pièces, la vulnérabilité, la version livrée et les conditions explicites du statut.
- Vérifier émetteur, identifiants produit, version, date et héritage des informations dans le document complet.
- Demander les justifications de not_affected ou les actions d’affected ; conserver under_investigation comme une incertitude.
- Réexaminer la déclaration lors d’une modification du build, des dépendances ou des hypothèses d’exécution.
Lire les statuts VEX et leurs conditions d’applicabilité →
Sources vérifiées le · OpenVEX · Specification v0.2.0
Signature et provenance du build
Demander des preuves de provenance interprétables
Une preuve fournisseur devient exploitable lorsque son contenu et son périmètre peuvent être rapprochés d’un produit livré. La confiance doit porter sur une identité et une plateforme autorisées, avec des attentes explicites sur le processus de production.
- Identifier artefact, digest, format d’attestation et mode de distribution de la provenance.
- Distinguer le niveau SLSA Build déclaré de l’évaluation réelle des exigences et de la confiance dans la plateforme.
- Documenter les champs et dépendances non établis ; une liste vide ne démontre pas leur absence.
Lire la fiche de provenance avant déploiement →
Sources vérifiées le · SLSA 1.2 · Build: Verifying artifacts · SLSA 1.2 · Build: Provenance · SLSA 1.2 · Build: Track Basics · in-toto · Statement v1 · Sigstore · Verifying Signatures