En 2027, Oracle intégrera le chiffrement postquantique avec Java 8 et 11

Postquantique : un mécanisme de chiffrement hybride pour les flux TLS

Comme promis, le JDK 27 intègre des algorithmes et un schéma d’échange de clés de chiffrement postquantique hybride pour le protocole TLS 1.3 (JEP 527). Le fournisseur et la communauté s’appuient sur une spécification fraîchement publiée par l’IETF. Il s’agit plus particulièrement de protéger les canaux de transfert de données qui intègre le protocole contre les attaques de type « harvest now, decrypt later ». Celles-ci consistent à collecter et à stocker des paquets chiffrés afin de les déchiffrer plus tard, lorsque les ordinateurs quantiques suffisamment puissants seront commercialisés.

Ici, il s’agit de combiner des algorithmes à treillis ML-KEM (Lattice-Based Key-Encapsulation Mechanism) avec des algorithmes de chiffrement éphémères à courbe elliptique de Diffie-Hellman (ECDHE) dans un processus de chiffrement asymétrique. Le mécanisme prend en charge des clés ML-KEM de 768 et 1024 bits.

Java 27 a par ailleurs le droit aux dernières déclinaisons d’algorithmes de chiffrement postquantique ML-KEM et ML-DSA pour les clés privées. Les performances de ces algorithmes ont également été améliorées, tandis que la JEP 538 fournit une troisième préversion pour l’API d’encodage des objets représentant des clés de chiffrement, des certificats et leur révocation au format PEM (Privacy Ehanced Mail).

Oracle justifie l’implémentation d’un mécanisme hybride par sa popularité et comme un moyen d’offrir une « garantie minimale de sécurité contre les attaques traditionnelles et quantiques ». Les mainteneurs n’écartent pas l’idée d’utiliser uniquement des clés ML-KEM avec le protocole TLS.

Oracle avait déjà l’idée de rétroporter ce dispositif de sécurité pour les versions LTS 8, 11, 17 et 21 de Java. Il faut désormais ajouter Java 25 à cette liste. Surtout, le fournisseur a présenté un calendrier détaillé. Le JDK 25 intégrait déjà les JEP 496 (ML-KEM) et 497 (ML-DSA), introduit avec le JDK 24. Cette version 25 embarquera la JEP 527 évoquée ci-dessus dès le mois d’octobre 2026. Au même moment, les JDK 17 et 21 intégreront les JEP 496 et 497, tandis que le protocole pour TLS sera porté au cours du premier semestre 2027. Les versions 8 et 11 du JDK auront le droit à l’ensemble de ces ajouts au cours du deuxième semestre 2027.

« Nous étageons ces modifications parce que nous voulons nous assurer que l’implémentation [du chiffrement PQC hybride] est stable, en récoltant le plus de retour possible au cours de cet effort de rétroportage », affirme Donald Smith, vice-président de la gestion produit pour Java SE chez Oracle, lors d’un point presse. « Pour être franc, plus l’on remonte le temps pour rétroporter du code, plus c’est difficile », ajoute-t-il. « Comme vous pouvez l’imaginer, cette modification touche de nombreux composants internes du JDK. Rappelez-vous que le JDK 21 a introduit un tout nouveau modèle de gestion des threads sur la plateforme Java, tandis que Java 9 a introduit les modules. C’est un effort significatif que nous ne prenons pas à la légère ».

Dans le respect de la philosophie « Tip and Tail », le JDK 28 pourrait intégrer la prise en charge de système de chiffrement uniquement basé sur ML-KEM. En attendant, l’accès anticipé à Java 28 est centré sur le projet Valhalla, lancé depuis 2014. Celui-ci doit permettre à la JVM de prendre en charge plus de types de données différents. Il s’agit plus précisément de « réduire l’écart entre les objets Java et les types primitifs, en commençant par les classes et les objets de valeur ». Là, l’objectif est de renforcer la pertinence de Java pour les charges de travail analytiques, les calculs distribués et l’IA.

Des gains de performance vendues comme bénéfique pour les cas d’usage IA

En matière d’IA justement. Le JDK 27 a surtout le droit à des améliorations de performances avec les algorithmes de vectorisation (JEP 537), résultant de la douzième incubation (!) de la Vector API, et la JEP 534.

La JEP 534 réduit par défaut de 12 à 8 octets le header des objets présent en mémoire de la JVM. Cela permettrait de faire chuter la consommation en RAM des applications de 10 à 20 %.

La septième préversion de la concurrence structurée (JEP 533) gagne en simplicité (moins de boilerplates pour la configuration) et en fiabilité (gestion des erreurs et des exceptions unifiée). Elle peut être utile pour la suspension de tâches en évitant les fuites de threads, ce qui peut être intéressant avec des agents IA. Il s’agit à terme d’éviter le gaspillage de ressources GPU (via le projet Babylon). Pour l’instant, l’on se contentera des gains d’utilisation des CPU et du réseau.

Il en va de même pour l’API gérant les « constantes paresseuses » (JEP 531). Ce mécanisme accélère l’initialisation des objets contenant des données immuables au sein de la JVM. L’idée serait de charger plus rapidement des paramètres fixes de réseaux de neurones et le dictionnaire d’embeddings par exemple. Le JDK 27 prend ainsi en charge des constantes paresseuses pour les structures List, Set et Map. Les arguments isInitialized() et orElse(), incompatibles avec la déclaration d’intention de la JEP en sus d’être instables, ont été supprimés.

En réalité, la JEP 537 permet de créer ou d’indexer des vecteurs sans GPU à un coût raisonnable. La JEP 534 vise à réduire les coûts induits par Apache Spark ou Kafka. La JEP 531 réduit le temps de démarrage des microservices bâtis avec Spring Boot, Quarkus et Helidon. La JEP 533 permet de « tuer » les requêtes inutiles à une base de données répliquées sur plusieurs serveurs.

Par ailleurs, le garbage collector (ou ramasse-miettes) G1 est activé par défaut dans tous les environnements (JEP 523) pour la VM Hotspot. Il s’agit d’aligner les performances de G1 avec Serial GC sur les petits systèmes, de profiter d’une latence en baisse et d’un comportement stable quel que soit l’environnement (local, conteneur).

Enfin la JEP 536, elle doit permettre de masquer des arguments de ligne de commande et des valeurs initiales de variables d’environnement au sein du framework de diagnostic et de supervision JFR (JDK Flight Recorder).

Des mises à jour de sécurité mensuelles pour les clients de Java SE

Les projets Valhalla, Babylon, Panama et Detroit étant en cours de gestation, les véritables changements en matière d’IA sont périphériques au langage de programmation et à ses machines virtuelles.

Outre Helidon 27 et l’extension VS Code de la plateforme Java (combinable avec GitHub Copilot et Claude Code), Oracle a surtout annoncé l’accélération des mises à jour de sécurité pour les clients de Java SE. À partir du 17 novembre 2026, les mises à jour de sécurité critiques (critical security patch updates ou CSPU) seront lancées tous les mois contre tous les trimestres auparavant puis, en 2027, plusieurs fois par mois.

« L’IA transforme le paysage de la cybersécurité en augmentant la vitesse et l’échelle de la découverte de vulnérabilités et la remédiation », affirme Michele DiSerio, directrice marketing produit Java chez Oracle. Un phénomène observé chez les défenseurs et les attaquants.

Et Oracle de préciser qu’il faudra pour cela mettre plus régulièrement à jour pour que ce système. « Ces clients devront connaître, planifier, tester et réparer [leurs applications] ».

Pour rappel, Oracle et la communauté ont convenu d’un règlement temporaire concernant les contributions IA. Elles sont globalement interdites, mais la nécessaire protection des applications Java – s’appuyant sur Java SE ou non – pourrait changer la donne. « Nous ferons évoluer cette politique au fur et à mesure », indique Donald Smith. Pour l’instant, l’intrication des éléments liés à l’OpenJDK, des librairies propriétaires et le fait que Java est utilisé pour propulser des applications critiques depuis près de 30 ans invitent le fournisseur à la prudence.