mthiim/dilithium-java - Implémentation en Java d’un algorithme cryptographique résistant à l’informatique quantique

• Implémentation de Dilithium 3.1 en Java, avec les opérations primitives encapsulées dans un JCE provider, permettant d’utiliser la génération de clés, la signature et la vérification via les interfaces de chiffrement Java standardisées
• Dans le contexte où RSA et ECC sont vulnérables aux attaques par ordinateurs quantiques utilisant l’algorithme de Shor, il s’agit d’une implémentation destinée à expérimenter et apprendre Dilithium, l’un des schémas de signature numérique post-quantique sélectionnés par le NIST
• Dilithium appartient à la famille d’algorithmes CRYSTALS ; cette implémentation, basée sur des réseaux algébriques, a été réalisée à partir de l’implémentation de référence en C et de la documentation, tandis que SHAKE128/256, utilisés en interne, sont fournis via une dépendance à Bouncy Castle
• Prend en charge les trois niveaux de sécurité documentés 2, 3 et 5 ; les trois niveaux utilisent un deterministic signature scheme et passent les tests KAT du package officiel
• Le flux d’utilisation avec JCE consiste à enregistrer DilithiumProvider, puis à effectuer la génération de clés, la signature, la vérification et la reconstruction de clés avec KeyPairGenerator.getInstance("Dilithium"), Signature.getInstance("Dilithium") et KeyFactory.getInstance("Dilithium")
  • Le niveau de sécurité se spécifie avec DilithiumParameterSpec.LEVEL2, LEVEL3, LEVEL5 ou getSpecForSecurityLevel()
  • Les clés publiques et privées obtiennent leur représentation en octets via .getEncoded(), puis sont sérialisées et désérialisées dans un format compatible avec l’implémentation de référence
  • La représentation en octets n’encode pas le parameter spec ; lors de la reconstruction d’une clé, il faut donc préciser le parameter spec dans DilithiumPublicKeySpec ou DilithiumPrivateKeySpec
• Fournit l’utilitaire KAT.java, qui lit les fichiers de requêtes des known-answer tests du package Dilithium officiel et génère des fichiers de réponse ; ses arguments d’exécution sont au format <input-request-file> <output-response-file> <level>
• L’implémentation actuelle reflète Dilithium 3.1 et diffère de FIPS 204 ou de la version ML-DSA en cours de standardisation
• Implémentation écrite « for fun » en quelques jours : ce n’est pas du production-grade code, elle n’a pas fait l’objet d’un audit de vulnérabilités par un tiers, et aucune garantie ni aucun support ne sont fournis
• Distribué sous licence Apache 2.0

[GN⁺]

Commentaires Hacker News

• Je suis ravi de voir que mon projet attire l’attention sur Hacker News. C’est une implémentation purement ludique, inspirée de l’article et de l’implémentation de référence
  Tous les cas de test fournis passent, mais je l’ai surtout faite pour le plaisir et pour voir si elle s’intégrait naturellement à l’interface JCE standard. N’hésitez pas à poser des questions ou à faire des retours

  • Je me demande ce qu’il faudrait pour l’utiliser en production. J’aimerais aussi savoir s’il existe des bibliothèques Java de cryptographie post-quantique suffisamment prêtes pour un usage en environnement réel

• L’essentiel des parties centrales de cette implémentation ludique de Dilithium se trouve ici : https://github.com/mthiim/dilithium-java/blob/main/src/main/...

  • La spécification de Dilithium est aussi ici : https://pq-crystals.org/dilithium/data/dilithium-specificati...

• Je me demande si c’est une bonne idée d’utiliser des algorithmes de cryptographie post-quantique en surcouche d’algorithmes plus établis et largement utilisés comme RSA/ECDSA
  La cryptographie post-quantique reste encore trop de pointe pour être vraiment pratique à l’usage

  • En pratique, c’est bien ce que semble faire la communauté
    Cloudflare a récemment activé la cryptographie post-quantique et utilise X25519+Kyber [0]. La cryptographie post-quantique de Signal repose sur la même approche [1].
    Cette tendance semble venir du fait qu’il y a quelques années, un algorithme post-quantique a été cassé sur un ordinateur classique [2].
    Désormais, un attaquant doit casser à la fois l’algorithme classique et l’algorithme post-quantique
    [0] https://blog.cloudflare.com/post-quantum-to-origins/
    [1] https://signal.org/blog/pqxdh/
    [2] https://www.quantamagazine.org/post-quantum-cryptography-sch...
  • À ma connaissance, l’algorithme de Shor reste encore peu réaliste aujourd’hui. Il faudrait bien plus de qubits que ce qui est actuellement possible pour l’exécuter dans un délai raisonnable
    Il en faudrait des millions, alors que les appareils les plus avancés n’en ont aujourd’hui au mieux que quelques centaines. Pendant les prochaines années, voire les prochaines décennies, je ne pense pas qu’on doive trop s’inquiéter des algorithmes post-quantiques dans le code en production
  • La norme actuellement généralement acceptée, sans faire l’unanimité, est le chiffrement hybride. Ce n’est pas le même « hybride » que dans KEM/DEM, mais en pratique on l’utilise souvent avec un schéma de chiffrement hybride KEM/DEM
    Cette approche garantit qu’il faut casser à la fois l’algorithme classique et l’algorithme post-quantique pour accéder au texte en clair. Savoir s’il suffit d’envelopper simplement le chiffrement, ou s’il faut utiliser un combinateur KEM hybride comme dans l’exemple de Campagna et Petcher, est une question plus subtile qui demande un jugement plus pointu que le mien
  • Si les ordinateurs quantiques deviennent plus pratiques de notre vivant, il ne faudrait pas que les secrets d’aujourd’hui soient exposés plus tard à ce type d’analyse. Faire évoluer les ordinateurs quantiques n’est pas aussi simple que le passage des tubes à vide et des transistors aux circuits intégrés, mais les estimations des experts sur la difficulté vont de « très très très difficile » à « cela pourrait rester physiquement impossible »
    Dans tous les cas, cela semble plus plausible que de casser par force brute les clés de chiffrement des standards modernes, donc il y a de bonnes raisons de donner la priorité dès aujourd’hui à la sécurité post-quantique.
    Cela dit, il faut aussi rester prudent. Si les algorithmes PQ présentent des vulnérabilités de canal auxiliaire ou d’implémentation, cela peut être bien pire. Il suffit d’imaginer, dans le pire des cas, une faille d’exécution de code à distance dans une implémentation PQ. Mieux vaut donc avancer avec prudence et soumettre le code à une revue stricte
  • Il n’y a pas de risque concret à utiliser ensemble une cryptographie post-quantique et une cryptographie classique, dès lors que la combinaison est conçue pour que l’ensemble ne s’effondre pas si l’une des deux est cassée
    Pour l’échange de clés, c’est relativement simple, et selon la méthode il suffit de faire un XOR des sorties ou de les concaténer

• Le README mentionne une dépendance à Bouncy Castle, et BC inclut déjà plusieurs schémas de signature PQC en Java. Voir https://doc.primekey.com/bouncycastle/interoperability#Inter... et https://github.com/bcgit/bc-java

• Il y a quelques jours, Daniel Bernstein a averti que la NSA cherchait à diffuser des implémentations de cryptographie post-quantique défectueuses. Je n’arrive pas à retrouver le lien

  • Le billet en question est ici. En revanche, il parle de Kyber, pas de Dilithium
    https://news.ycombinator.com/item?id=37756656

• Voici aussi une implémentation Java en fichier unique de sphincs+, un autre schéma de signature post-quantique, que quelqu’un a écrite/portée
  https://github.com/Peergos/sphincsplus

• « On sait depuis longtemps que les algorithmes cryptographiques RSA et ECC sont vulnérables aux attaques d’ordinateurs quantiques utilisant l’algorithme de Shor. »
  Si c’est vrai et qu’un ordinateur quantique de cette ampleur apparaît réellement, je me demande quel serait l’impact sur Bitcoin

  • Les fonds seraient déplacés avant que cela ne devienne un problème. Et même si cela arrivait vraiment, il suffirait de faire un fork au premier point d’attaque connu pour y intégrer une cryptographie post-quantique

• « Il s’agit d’une implémentation écrite pour le plaisir en quelques jours. Elle n’est pas destinée à du code de niveau production. Aucune garantie ni aucun support d’aucune sorte ne sont fournis. En revanche, elle peut être utile pour examiner et expérimenter des algorithmes post-quantiques. Vous l’utilisez à vos risques et périls. Si ces conditions ne vous conviennent pas, vous ne devez pas utiliser ce logiciel »