Guide des piliers
Blockchains prenant en charge Kyber et Dilithium
Kyber et Dilithium sont désormais des standards NIST appelés ML-KEM et ML-DSA. La question la plus difficile est de savoir quels projets blockchain les ont réellement intégrés, pour quelle fonction et à quelle maturité. Ce guide fournit un cadre de preuves strict.
Les résultats de recherche pour « blockchains prenant en charge Kyber/Dilithium » combinent souvent quatre éléments très différents : une bibliothèque cryptographique, un prototype académique, une feuille de route annoncée et un consensus de production ou une implémentation de portefeuille. Ils ne sont pas interchangeables. Cela est important car les blockchains exposent la cryptographie à de nombreux endroits, et une migration partielle peut être à la fois précieuse et incomplète.
La réponse courte est prudente : les preuves publiques et vérifiables de manière indépendante de l'adoption du réseau principal à l'échelle du protocole à la fois par ML-KEM et ML-DSA restent limitées. Ce n’est pas une critique d’un quelconque projet. La migration post-quantique modifie les formats de transaction, la conservation des clés, les coûts de validation, les ponts, les logiciels clients et les opérations. Un guide utile devrait récompenser des preuves précises plutôt que des affirmations générales.
Tout d’abord, utilisez correctement les noms actuels
Les noms hérités restent courants, mais le langage standard aide les équipes à évaluer la compatibilité et la portée de la mise en œuvre.
FIPS 203
ML-KEM, anciennement Kyber
ML-KEM est un mécanisme d'encapsulation de clé basé sur un réseau de modules. Il permet à deux parties d'établir un secret partagé sur un canal public, puis d'utiliser ce secret avec une cryptographie symétrique pour des tâches telles que le cryptage et l'authentification. NIST a finalisé FIPS 203 le 13 août 2024 avec trois jeux de paramètres : ML-KEM-512, ML-KEM-768 et ML-KEM-1024.
Lire FIPS 203FIPS 204
ML-DSA, anciennement Dilithium
ML-DSA est une norme de signature numérique basée sur un réseau de modules dérivée de CRYSTALS-Dilithium. Les signatures peuvent authentifier une clé d'autorisation et révéler des modifications non autorisées d'un message. Cela rend ML-DSA pertinent pour l'autorisation de transaction, les messages du validateur et du pont, les versions logicielles et les informations d'identification de longue durée.
Lire FIPS 204Pourquoi une blockchain a besoin à la fois d'une carte cryptographique et d'un plan de migration
Un KEM ne signe pas de transaction. Une signature ne crée pas automatiquement un transport réseau confidentiel. ML-KEM et ML-DSA résolvent donc des problèmes différents. Une chaîne peut adopter l'une en premier sans prendre en charge l'autre, et cette distinction doit rester visible dans la documentation, le portefeuille UX, les spécifications du protocole et les descriptions externes.
Pour ML-DSA, une équipe doit prendre en compte le modèle de compte, la dérivation d'adresse, la sérialisation des transactions, le budget de vérification des signatures, le comportement du pool de mémoire, les nœuds d'archivage, les portefeuilles matériels, les politiques multisignatures et la récupération sécurisée. Pour ML-KEM, il doit décider où appartiennent les canaux cryptés ou les secrets stockés, comment les clés sont authentifiées, comment le matériel de session tourne et si un mode hybride est nécessaire pendant la transition.
Les directives de migration du NIST indiquent que ses premières normes PQC peuvent et doivent être mises en œuvre dès maintenant, tandis que les ordinateurs quantiques qui menacent les systèmes actuels pourraient encore prendre des années ou des décennies. Il indique également que les algorithmes quantiques vulnérables seront obsolètes et finalement supprimés des normes NIST d'ici 2035. La page du projet NIST indique clairement qu'il s'agit d'une longue transition et non d'un changement du jour au lendemain.
« Nous encourageons les administrateurs système à commencer immédiatement à les intégrer dans leurs systèmes, car une intégration complète prendra du temps. »
Carte des preuves : des projets réels, catégorisés avec précision
Ceci n'est pas un classement. Il sépare ce que le matériel publiquement documenté soutient de ce qu'il ne prend pas en charge.
| Projet ou catégorie | Cryptographie publiquement documentée | Niveau de preuve | Kyber / Dilithium conclusion |
|---|---|---|---|
| Algorand | Signatures Falcon dans State Proofs et transaction sur le réseau principal autorisée par Falcon. | Implémentation spécifique et brief technique mainnet. | Véritable étape de signature PQC, mais Falcon est distinct de ML-KEM et ML-DSA. Ne l'étiquetez pas support Kyber/Dilithium. |
| Quantum Resistant Ledger (QRL) | Sa documentation fait référence à la création Extended XMSS HyperTree et aux clés de signature uniques. | Documentation du projet. | Un exemple de chaîne poursuivant une famille de signatures post-quantiques différente, pas une preuve de déploiement de FIPS 203 ML-KEM ou FIPS 204 ML-DSA. |
| Écosystème QRL v2.0 | L'écosystème QRL publie une bibliothèque de signature ML-DSA-87 FIPS 204 avec un contexte « ZOND » pour les applications QRL v2.0. | Preuve de bibliothèque, pas une réclamation sur le réseau principal à l'échelle du protocole. | La prise en charge spécifique de ML-DSA est documentée au niveau de la couche bibliothèque. La page de la bibliothèque n'établit pas de validation ML-KEM ou ML-DSA à l'échelle du réseau principal. |
| Cellframe | Son introduction indique que la plate-forme utilise Crystal Dilithium, Kyber 512 et Falcon. | Documentation officielle du projet, avec des détails de mise en œuvre limités. | Une référence directe au niveau du projet à la fois à Kyber et à Dilithium. Traitez la portée revendiquée comme documentée par Cellframe jusqu'à ce que le code, les paramètres et les détails d'activation soient vérifiés de manière indépendante. |
| QANplatform | Sa documentation indique que ML-DSA est utilisé via QAN XLINK pour signer des comptes. | Documentation officielle du projet, pas de jeu de paramètres nommé ML-DSA ou de preuve de transaction sur le réseau principal sur la page citée. | Conception spécifique de référence ML-DSA et de migration de signature. La documentation citée ne revendique pas la prise en charge de ML-KEM ou Kyber. |
| Recherche basée sur Hyperledger | Les documents de recherche modèlent ou prototypent l'intégration de Kyber et Dilithium dans des configurations de blockchain autorisées. | Preuve de faisabilité académique. | Utile pour l'évaluation technique, mais ne prouve pas qu'un stock Hyperledger Fabric ou un autre réseau de production est livré avec ML-KEM ou ML-DSA à l'échelle du protocole. |
| Écosystèmes EVM et majeurs Layer-1 | La recherche, les discussions sur l'abstraction de compte, les bibliothèques cryptographiques et les précompilations proposées apparaissent dans l'écosystème plus large des développeurs. | Varie selon la proposition et le référentiel. | Une bibliothèque ou une proposition ne modifie pas la validation consensuelle. Vérifiez la version réelle du client et l'activation de la chaîne avant de déclarer le support. |
| Autheo | Une feuille de route est en cours d'élaboration autour de Kyber, Dilithium et Falcon. | Feuille de route, pas de protection en direct. | Le travail post-quantique n’est pas encore intégré au système réel. Il ne faut pas la qualifier de sécurité actuelle de la chaîne. |
Algorand fournit l'exemple de limite le plus clair. Son chemin de réseau principal Falcon-1024 utilise un opcode Logic Signature et AVM falcon_verify. Le dossier publié décrit environ 1 280 signatures Falcon-1024 d'octets, des clés publiques de 1 793 octets et State Proofs produites tous les 256 tours. C'est une preuve solide d'un cas d'utilisation de Falcon, pas une raison pour remplacer Falcon par ML-KEM ou ML-DSA dans une réclamation concernant Kyber et Dilithium.
QRL propose une deuxième comparaison utile. Sa documentation présente les concepts de clé Extended XMSS HyperTree et de signature unique, qui démontrent que la « blockchain post-quantique » peut faire référence à des conceptions cryptographiques autres que les normes NIST basées sur un réseau. La documentation du QRL n'établit pas la prise en charge du ML-KEM ou du ML-DSA, donc ce guide ne prétend pas le faire.
Il existe des références d'algorithme NIST plus étroites qui méritent d'être suivies. La documentation publiée de la bibliothèque ML-DSA-87 de l'écosystème QRL identifie FIPS 204 et rapporte une signature ML-DSA-87 de 4 627 octets, tout en restant explicitement une preuve au niveau de la bibliothèque plutôt qu'une affirmation sur la validation du réseau principal. L'introduction officielle de Cellframe indique qu'il utilise Crystal Dilithium, Kyber 512 et Falcon. Il s'agit d'une revendication directe du projet couvrant les deux algorithmes, mais l'introduction citée ne fournit pas d'ensemble de paramètres ni de spécifications d'activation, les lecteurs doivent donc vérifier les versions de code et de protocole avant de s'appuyer sur une conclusion plus large.
QANplatform fournit un exemple distinct axé sur ML-DSA. Sa documentation de sécurité résistante aux quantiques indique que ML-DSA est utilisé via QAN XLINK pour signer des comptes de manière croisée et décrit un schéma de signature orienté vers la migration implémenté dans Go. La même page n'identifie pas de jeu de paramètres ML-DSA, de transaction de production ou de support ML-KEM ou Kyber. C'est pourquoi ce guide répertorie QANplatform dans la documentation spécifique ML-DSA, et non comme un déploiement confirmé à double algorithme.
Comment vérifier une demande d'assistance Kyber ou Dilithium
1. Identifiez la primitive
La revendication indique-t-elle ML-KEM ou ML-DSA, son jeu de paramètres et la fonction exacte ? Une référence générique à « NIST PQC » est insuffisante.
2. Localisez la limite d'exécution
Recherchez le type de transaction, le canal de nœud, le portefeuille, les informations d'identification, la preuve d'état, le pont ou le API où la vérification ou l'encapsulation a lieu.
3. Confirmez l'état du réseau
Vérifiez les notes de version, le code source, les versions de protocole, les vecteurs de test et une activation de testnet ou de réseau principal. Séparez l’opt-in du comportement obligatoire.
4. Mesurer les coûts
Enregistrez la taille des signatures et des clés publiques, la latence de vérification, l'utilisation de la mémoire, l'effet des frais, l'impact sur la bande passante et la prise en charge sur les appareils mobiles ou matériels.
5. Vérifiez les mécanismes de migration
Évaluez les mises à niveau des comptes, la rotation des clés, le multisig, la récupération, la rétrocompatibilité, l'interopérabilité des ponts et la façon dont la cryptographie existante sera retirée.
6. Examiner les preuves indépendantes
Recherchez des tests reproductibles, des audits, une conformité aux normes, un suivi des problèmes et une description claire des risques non résolus plutôt qu'une simple copie promotionnelle.
Où ML-KEM et ML-DSA pourraient s'intégrer dans une architecture blockchain
ML-DSA a le rôle le plus évident face à la blockchain, car les blockchains dépendent déjà des signatures. Une future intégration pourrait autoriser une transaction de compte, un vote de validateur, une attestation de pont, une mise à jour Oracle, une action d'administrateur ou une version logicielle. Chaque utilisation a une fréquence de vérification et un mode de défaillance différents. Une signature qui fonctionne dans un pipeline de versions peut être trop volumineuse ou trop lente pour un chemin de transaction à volume élevé.
ML-KEM appartient généralement à un calque différent. Cela peut aider deux parties à établir un secret pour le transport crypté ou le matériel stocké. Cela peut être important pour un portefeuille connecté à un service, une communication privée de nœud à nœud, des données hors chaîne cryptées, un échange d'informations d'identification ou un canal d'opérations de validateur. Il ne cache pas à lui seul les données du grand livre public et ne prouve pas qu'un propriétaire de portefeuille a autorisé un transfert.
La conception des adresses est une source courante de confusion. Si une adresse de compte s'engage sur une clé de vérification publique, un schéma de signature post-quantique peut nécessiter une nouvelle famille d'adresses, un champ de transaction balisé ou une couche d'abstraction de compte qui est acheminée vers le bon vérificateur. Wallets doit alors afficher clairement le mode de sécurité, éviter une rétrogradation accidentelle et protéger les utilisateurs de la réutilisation d'une adresse classique lorsque l'application attend un compte post-quantique.
Les réseaux de contrats intelligents nécessitent également un choix explicite en matière de vérification. Une fonctionnalité client native, un opcode de machine virtuelle, une précompilation et une bibliothèque de contrats ont des propriétés de coût et de confiance très différentes. L'intégration native peut être efficace mais nécessite une version de protocole. La mise en œuvre d'un contrat peut être plus facile à tester mais peut dépasser les budgets pratiques de gaz ou d'exécution. Le chemin de vérification documenté Falcon de Algorand illustre pourquoi l'emplacement du vérificateur devrait faire partie de chaque réclamation.
La bonne architecture peut donc être mise en scène. Commencez par des systèmes d'inventaire et de signature de logiciels, établissez des vecteurs de test et des références reproductibles, prenez en charge les comptes ou les canaux opt-in le cas échéant, puis décidez si une mise à niveau consensuelle est justifiée. Publier ce qui reste classique est une force. Il permet aux intégrateurs d’évaluer le risque résiduel sans confondre une expérience ciblée avec une sécurité post-quantique globale.
Le rôle du Autheo dans cette transition
Autheo développe sa feuille de route Kyber, Dilithium et Falcon pour de futurs travaux de protocole, d'identité et de gestion des clés. Ce travail n'est pas encore intégré au système actif, et il serait inexact d'affirmer que ces algorithmes sécurisent actuellement Autheo. Le staking et les frais de transaction sont actifs aujourd'hui ; les couches de cryptographie post-quantique, TheoID, de calcul, de stockage, d'inférence IA et THEO AI restent en développement.
Toute implémentation future doit être évaluée avec les mêmes critères que ceux utilisés pour toutes les autres chaînes : algorithme et paramétrage exacts, limites cryptographiques, chemin de migration, tests reproductibles, examen indépendant, coût opérationnel et divulgation claire de ce qui n'a pas encore migré. Une feuille de route crée une direction pour ce travail. Cela ne remplace pas la preuve.
Autheo fonctionne sur Proof of Autheo, un modèle Hybrid PoA/PoS. Renseignez-vous sur l'actuel architecture consensuelle séparément du futur développement post-quantique.
Ressources Autheo associées
Guide de la blockchain post-quantique
Comprendre le modèle de menace plus large, le cadre de migration et l'étude de cas Algorand.
Comparaison Algorand
Comparez les architectures et examinez les références des projets.
Comparaison Ethereum
Une comparaison de base pour le contexte de migration cryptographique Layer-1.
Centre de FAQ
Parcourez les réponses canoniques Autheo organisées pour les développeurs et les entreprises.
Qu'est-ce que le guide complet Autheo
Lisez le guide fondamental de l’architecture unifiée prévue du Autheo.
Déployez votre premier contrat intelligent
Commencez par le flux de travail du générateur et les ressources de développement.
Qu'est-ce que Layer-0 ?
Passez en revue le modèle d'architecture Layer-0 et Layer-1.
Programme de sécurité
Examinez les contacts de sécurité et les informations de divulgation responsable.
FAQ sur la blockchain Kyber et Dilithium
Exigez des preuves pour chaque affirmation cryptographique
La bonne question n’est pas de savoir si un projet est dit quantiquement sûr. Il s’agit de savoir où, comment et avec quelles preuves vérifiables de manière indépendante.
Explorez Autheo pour les constructeurs