mthiim/dilithium-java – Implementierung eines quantencomputerresistenten Kryptografie-Algorithmus in Java

 (github.com/mthiim)
1 Punkte von GN⁺ 2023-10-24 | 1 Kommentare | Auf WhatsApp teilen
  • Implementierung von Dilithium 3.1 in Java, bei der die primitiven Operationen als JCE Provider gekapselt sind; Schlüsselgenerierung, Signieren und Verifizieren können über die standardisierten Java-Kryptografie-Schnittstellen genutzt werden
  • Vor dem Hintergrund, dass RSA und ECC anfällig für Angriffe durch Quantencomputer mit Shor's algorithm sind, handelt es sich um eine Implementierung zum Experimentieren und Lernen mit Dilithium, einem der von NIST ausgewählten Post-Quantum-Verfahren für digitale Signaturen
  • Gehört zur CRYSTALS-Algorithmensammlung; Dilithium basiert auf algebraischen Gittern und wurde anhand der C-Referenzimplementierung und der Dokumentation umgesetzt, während das intern verwendete SHAKE128/256 über die Abhängigkeit Bouncy Castle bereitgestellt wird
  • Unterstützt alle dokumentierten Sicherheitsstufen 2, 3 und 5; alle drei Stufen verwenden ein deterministic signature scheme und bestehen die KAT-Tests des offiziellen Pakets
  • Der JCE-Nutzungsablauf besteht darin, zunächst DilithiumProvider zu registrieren und anschließend mit KeyPairGenerator.getInstance("Dilithium"), Signature.getInstance("Dilithium") und KeyFactory.getInstance("Dilithium") Schlüsselgenerierung, Signieren, Verifizieren und Schlüsselwiederherstellung auszuführen
    • Die Sicherheitsstufe wird mit DilithiumParameterSpec.LEVEL2, LEVEL3, LEVEL5 oder getSpecForSecurityLevel() angegeben
    • Öffentliche und private Schlüssel erhalten ihre Byte-Darstellung über .getEncoded() und werden in einem mit der Referenzimplementierung kompatiblen Format serialisiert und deserialisiert
    • Die Byte-Darstellung kodiert die parameter spec nicht, daher muss bei der Schlüsselwiederherstellung die parameter spec in DilithiumPublicKeySpec oder DilithiumPrivateKeySpec explizit angegeben werden
  • Stellt das Utility KAT.java bereit, das die known-answer test-Request-Dateien des offiziellen Dilithium-Pakets liest und Response-Dateien erzeugt; die Laufzeitargumente haben das Format <input-request-file> <output-response-file> <level>
  • Die aktuelle Implementierung entspricht Dilithium 3.1 und unterscheidet sich von den in Standardisierung befindlichen Versionen FIPS 204 bzw. ML-DSA
  • Eine „for fun“ innerhalb weniger Tage geschriebene Implementierung; kein production-grade code, keine Prüfung auf Schwachstellen durch Dritte und keinerlei Garantie oder Support
  • Veröffentlicht unter der Apache-2.0-Lizenz

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-10-24
Hacker-News-Kommentare

  • Es freut mich zu sehen, dass mein Projekt auf Hacker News Aufmerksamkeit bekommt. Das hier ist eine reine Spielzeug-Implementierung, inspiriert von dem Paper und der Referenzimplementierung.
    Alle bereitgestellten Testfälle bestehen, aber ich habe es hauptsächlich zum Spaß gebaut und um zu sehen, ob es sich sauber in die standardmäßigen JCE-Schnittstellen einfügt. Bei Fragen oder Feedback einfach gern melden.

    • Mich würde interessieren, was nötig wäre, um das in einem echten Dienst einzusetzen. Ich würde auch gern wissen, ob es Java-Bibliotheken für Post-Quanten-Kryptografie gibt, die für den Einsatz in Produktionsumgebungen ausreichend reif sind.

  • Die zentralen Teile dieser Dilithium-Spielzeug-Implementierung sind größtenteils hier zu sehen: https://github.com/mthiim/dilithium-java/blob/main/src/main/...

  • Ich frage mich, ob es eine gute Idee ist, Post-Quanten-Kryptografie-Algorithmen zusätzlich zu etablierteren und weiter verbreiteten Algorithmen wie RSA/ECDSA zu verwenden.
    Post-Quanten-Kryptografie ist noch so neu, dass sie sich noch nicht besonders bequem einsetzen lässt.

    • Tatsächlich scheint genau das die Community zu tun.
      Cloudflare hat vor Kurzem Post-Quanten-Kryptografie aktiviert und verwendet X25519+Kyber [0]. Die Post-Quanten-Kryptografie von Signal nutzt denselben Ansatz [1].
      Dieser Trend scheint daraus entstanden zu sein, dass vor einigen Jahren ein Post-Quanten-Algorithmus auf einem klassischen Computer gebrochen wurde [2].
      Ein Angreifer muss nun sowohl den klassischen als auch den Post-Quanten-Algorithmus brechen.
      [0] https://blog.cloudflare.com/post-quantum-to-origins/
      [1] https://signal.org/blog/pqxdh/
      [2] https://www.quantamagazine.org/post-quantum-cryptography-sch...
    • Soweit ich weiß, ist der Shor-Algorithmus bisher noch nicht realistisch, weil für eine Ausführung in vertretbarer Zeit sehr viel mehr Qubits nötig wären, als derzeit möglich sind.
      Man bräuchte wohl Millionen von Qubits, während modernste Geräte derzeit bestenfalls im Bereich einiger Hundert liegen. Ich glaube daher nicht, dass wir uns in den nächsten Jahren, vielleicht sogar Jahrzehnten, in produktivem Code große Sorgen um Post-Quanten-Algorithmen machen müssen.
    • Der derzeit weitgehend akzeptierte, wenn auch nicht unumstrittene Standard ist hybride Verschlüsselung. Das ist nicht dasselbe wie „hybrid“ im Sinne von KEM/DEM, wird aber normalerweise zusammen mit einem hybriden KEM/DEM-Kryptosystem verwendet.
      Dieser Ansatz stellt sicher, dass man sowohl den klassischen als auch den Post-Quanten-Algorithmus brechen muss, um auf den Klartext zuzugreifen. Ob man die Verschlüsselung einfach nur einhüllt oder wie im Beispiel von Campagna und Petcher einen hybriden KEM-Kombinator verwendet, ist eine subtilere Frage und erfordert ein differenzierteres Urteil, als ich es geben kann.
    • Falls Quantencomputer zu unseren Lebzeiten praktikabler werden, sollten heutige Geheimnisse später nicht für solche Analysen offenliegen. Das Skalieren von Quantencomputern ist zwar nicht so geradlinig wie die Entwicklung von Vakuumröhren und Transistoren hin zu integrierten Schaltkreisen, aber die Einschätzungen von Fachleuten zur Schwierigkeit reichen von „sehr, sehr, sehr schwer“ bis zu „wird physikalisch unmöglich bleiben“.
      In jedem Fall erscheint es wahrscheinlicher, als heutige Standardschlüssel per Brute Force zu brechen, daher gibt es gute Gründe, schon heute Post-Quanten-Sicherheit zu priorisieren.
      Vorsicht ist aber ebenfalls angebracht. Wenn PQ-Algorithmen Seitenkanäle oder Implementierungsschwächen haben, kann das die Lage sogar deutlich verschlimmern. Im schlimmsten Fall hat eine PQ-Implementierung etwa eine Remote-Code-Execution-Schwachstelle. Deshalb ist es sinnvoll, vorsichtig vorzugehen und den Code streng zu prüfen.
    • Die gemeinsame Verwendung von Post-Quanten-Kryptografie und bestehender Kryptografie in einer Weise, bei der nicht das gesamte Konstrukt zusammenbricht, wenn eine der beiden gebrochen wird, birgt praktisch kein Risiko.
      Beim Schlüsselaustausch ist das relativ einfach; je nach Verfahren kann man die Ausgaben per XOR verknüpfen oder aneinanderhängen.

  • In der README wird eine Abhängigkeit von Bouncy Castle erwähnt, und BC enthält bereits mehrere Java-basierte PQC-Signaturverfahren. Siehe https://doc.primekey.com/bouncycastle/interoperability#Inter... und https://github.com/bcgit/bc-java.

  • Vor ein paar Tagen warnte Daniel Bernstein, die NSA wolle fehlerhafte Post-Quanten-Kryptografie-Implementierungen verbreiten. Ich finde den Link gerade nicht.

  • Hier gibt es eine selbst geschriebene/portierte Single-File-Java-Implementierung von sphincs+, einem weiteren Post-Quanten-Signaturverfahren.
    https://github.com/Peergos/sphincsplus

  • „Es ist seit Langem bekannt, dass die Kryptografiealgorithmen RSA und ECC anfällig für Angriffe durch Quantencomputer mit dem Shor-Algorithmus sind.“
    Wenn das stimmt und Quantencomputer in dieser Größenordnung tatsächlich Realität werden, frage ich mich, welche Auswirkungen das auf Bitcoin hätte.

    • Die Coins würden bewegt werden, bevor es zum Problem wird. Und selbst wenn es tatsächlich dazu käme, könnte man ab dem ersten bekannten Angriffspunkt einen Fork mit Post-Quanten-Kryptografie einführen.

  • „Dies ist eine Implementierung, die ich innerhalb weniger Tage zum Spaß geschrieben habe. Sie ist nicht als produktionsreifer Code gedacht. Es wird keinerlei Garantie oder Support irgendeiner Art gegeben. Sie kann aber nützlich sein, um sich Post-Quanten-Algorithmen anzusehen und damit zu experimentieren. Nutzung auf eigene Gefahr. Wenn Ihnen diese Bedingungen nicht gefallen, sollten Sie diese Software nicht verwenden.“