Wie HotSpot-Intrinsics ML-KEM und ML-DSA im JDK beschleunigen
Victoria Shinder1 Min. LesezeitEin am 30. September auf Inside Java erschienener Artikel erklärt, woher die Post-Quanten-Verfahren des JDK ihre Geschwindigkeit haben. Das JDK unterstützt ML-KEM (FIPS 203), ML-DSA (FIPS 204) und die hashbasierten HSS/LMS-Signaturen nach RFC 8554, alle aus Gründen der Portabilität in Java implementiert. Für die leistungskritischsten Methoden kann HotSpot ein Intrinsic einsetzen: plattformspezifischen Maschinencode, der CPU-Funktionen wie SHA-3- und SHA-256-Beschleunigung, Vektorbefehle und effiziente Modulararithmetik nutzt.
Ein Intrinsic ersetzt den Java-Code nicht. Mit @IntrinsicCandidate markierte Methoden können ausgetauscht werden, wenn die Plattform eine Implementierung hat, überall sonst bleibt die Java-Methode die Rückfallebene. Die Regel des Artikels für Kandidaten: Die Methode muss teuer sein, häufig aufgerufen werden und in Maschinencode spürbar schneller laufen.
ML-KEM erfüllt diese Regel, weil seine heißen Pfade regelmäßige Berechnungen über Polynome mit genau 256 Koeffizienten sind: Vorwärts- und Rückwärts-Zahlentheoretische-Transformation, Multiplikation im Transformationsbereich, Polynomaddition, Barrett-Reduktion und Bit-Packing. Die Autoren betonen, dass Assembler nicht an sich schneller ist als Java; diese Operationen gewinnen, weil CPUs dieselben wenigen Schritte auf jeden Koeffizienten anwenden können. ML-DSA erledigt verwandte Arbeit, ist aber nicht austauschbar, da es den Modulus 8380417 statt 3329 bei ML-KEM nutzt; jedes Verfahren braucht daher eigene Intrinsics, ML-DSA etwa implDilithiumDecomposePoly. Bei der HSS/LMS-Verifikation fällt der Großteil der Zeit auf SHA-256, dort leistet das SHA-256-Intrinsic die meiste Arbeit.
Der Artikel zeigt den Durchsatz mit Intrinsics gegenüber reinem Java-Code auf Servern mit Ampere Altra und Intel Ice Lake und erklärt, wie die Diagramme zu lesen sind: 218 % Beschleunigung bedeuten 3,18-mal so schnell, nicht 2,18-mal.
Warum das wichtig ist
Post-Quanten-Schlüsselaustausch wird in TLS zum Standard, und seine Kosten fallen bei jedem Handshake eines Java-Servers an. Der Artikel zeigt den Ansatz des JDK: eine portable Implementierung behalten und die wenigen dominierenden Primitive beschleunigen, damit Anwendungen die Geschwindigkeit ohne eigenen plattformspezifischen Code bekommen.