Comment distinguer une technologie prometteuse d’une capacité exploitable ? Décrivez le problème résolu, les prérequis, les dépendances et le mode de retour arrière. Un prototype démontre un fonctionnement dans des conditions choisies ; l’exploitation demande aussi maintenance, compatibilité, supervision et réponse aux défaillances.
Pour la cryptographie, commencez par savoir où se trouvent les algorithmes, clés, certificats et échanges concernés. Pour les systèmes industriels, reliez toute modification aux contraintes de disponibilité et de sécurité physique. Les registres de protocoles et publications techniques aident à nommer les mécanismes, mais ne remplacent pas un essai dans un environnement autorisé.
Dans ce dossier
Cryptographie post-quantique · IoT · OT / ICS · Robotique · Semi-conducteurs
Préparer sa transition cryptographique post-quantique
Comment préparer une migration post-quantique ? Commencez par l’inventaire cryptographique, puis classez les usages selon la sensibilité des données et la difficulté de remplacement des systèmes. Vérifiez le statut des standards et les fonctions réellement livrées par les fournisseurs. La feuille de route attendue associe chaque service à ses dépendances, tests d’interopérabilité, critères de retour arrière et responsable. Il ne s’agit pas d’annoncer une échéance universelle pour tous les environnements.
Lire le guideLe fil de veille
Toute la veille internationale →Titres en cache · actualisation des sources indisponible · Dernière récupération réussie : 22 oct. 2026, 21:21
ITSEC Asia encourage l'Indonésie à se préparer aux menaces de l'informatique quantique - VOI.ID
via Google Actualités · agrégateur"La Chine, même pas peur" : rencontre avec Maud Vinet, l'égérie française de l'ordinateur quantique - L'Express
via Google Actualités · agrégateur1Password rend ses clés d'accès parées pour les attaques post-quantiques - Clubic
via Google Actualités · agrégateurLes électeurs de Starknet soutiennent des recherches sur l’après-Ethereum - TradingView
via Google Actualités · agrégateurAgents IA : des échanges déjà exposés au risque quantique - JDN
via Google Actualités · agrégateurRé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