Trois bibliothèques font tourner la quasi-totalité du chiffrement TLS de la planète, et elles ne prennent pas du tout le même chemin face à la cryptographie post-quantique. OpenSSL vient de pousser sa version 4.0.2 début septembre 2026, BoringSSL continue d’alimenter Chrome sans jamais publier de numéro de version, et wolfSSL vise les objets connectés avec un noyau qui tient dans quelques dizaines de kilo-octets. Le choix entre les trois n’est plus une question de goût : entre l’échéance ANSSI de 2027, la fin de vie d’OpenSSL 3.0 le 7 septembre 2026 et la montée en puissance de ML-KEM dans TLS 1.3, chaque équipe technique doit trancher avec des critères précis. Ce comparatif détaille les specs, les benchmarks mémoire, les CVE récentes, les licences et un guide de migration concret.

Pourquoi ce comparatif s’impose en 2026

La cryptographie post-quantique est passée du statut de curiosité académique à celui d’obligation réglementaire en l’espace de deux ans. L’ANSSI a fixé une trajectoire qui rend la certification post-quantique obligatoire dès 2027, et l’Union européenne pousse ses 27 États membres à livrer au moins un portefeuille d’identité numérique (EUDI) avant fin décembre 2026, un système qui repose entièrement sur des signatures numériques modernes. Dans ce contexte, la bibliothèque de chiffrement choisie par une équipe technique cesse d’être un détail d’infrastructure : elle détermine si une application peut migrer vers ML-KEM et ML-DSA sans réécriture complète.

OpenSSL, BoringSSL et wolfSSL couvrent à eux trois l’essentiel du chiffrement TLS mondial, des serveurs web aux navigateurs en passant par les capteurs industriels. Mais leurs trajectoires post-quantiques divergent nettement. OpenSSL a intégré nativement ML-KEM, ML-DSA et SLH-DSA dès la version 3.5.0, sortie le 8 avril 2025. BoringSSL avance par petites touches, au rythme des besoins internes de Google et de Cloudflare. wolfSSL, de son côté, a réécrit son implémentation post-quantique pour supprimer sa dépendance à la bibliothèque tierce liboqs, un chantier achevé avec la version 5.9.2 publiée le 23 juin 2026.

Ce comparatif s’adresse aux équipes qui doivent choisir une pile TLS pour un projet neuf, migrer une application existante avant l’échéance post-quantique, ou simplement comprendre pourquoi leur fournisseur cloud a changé de comportement lors du dernier audit de sécurité. Nous nous appuyons uniquement sur des données publiées par les projets eux-mêmes, par le NIST dans sa spécification FIPS 203, par Cloudflare et par des bases de vulnérabilités publiques.

Le point commun des trois projets reste leur dépendance aux mêmes algorithmes normalisés. Aucun n’a inventé son propre schéma post-quantique maison : tous s’appuient sur ML-KEM et ML-DSA tels que définis par le NIST, ce qui limite le risque de verrouillage propriétaire. La différence se joue donc ailleurs, sur la rapidité d’intégration, la qualité de la documentation, l’empreinte mémoire et le modèle de support, quatre critères que nous détaillons dans les sections suivantes avec des chiffres vérifiables.

OpenSSL, le standard historique sous tension

OpenSSL reste la bibliothèque de chiffrement la plus déployée au monde, présente par défaut dans la majorité des distributions Linux, dans curl, dans nginx et dans une bonne partie des runtimes applicatifs. Le projet a basculé sa branche 3.x sous licence Apache 2.0, ce qui simplifie son intégration dans des produits commerciaux sans les ambiguïtés de l’ancienne licence OpenSSL/SSLeay.

La version 3.5.0, livrée le 8 avril 2025, a marqué un tournant : elle a apporté le support natif des trois algorithmes post-quantiques normalisés par le NIST, ML-KEM (FIPS 203), ML-DSA (FIPS 204) et SLH-DSA (FIPS 205), sans provider externe ni patch tiers. Cette même version a aussi changé le comportement par défaut de TLS 1.3 en ajoutant le groupe hybride X25519MLKEM768 à la liste des groupes proposés lors d’une négociation.

Le calendrier de versions s’est accéléré depuis. La branche 3.0 a atteint sa fin de vie le 7 septembre 2026, cinq ans jour pour jour après sa sortie, forçant les équipes encore dessus à migrer vers 3.5 (LTS, maintenue jusqu’au 8 avril 2030) ou vers la nouvelle branche majeure 4.0. La version 4.0.2 est la dernière stable au 25 août 2026, et le projet a publié la première alpha de la 4.1.0 le 9 septembre 2026, une mouture qui promet un support de DTLS 1.3, du KDF IKEv2, du mécanisme GREASE et surtout des optimisations de performance pour la cryptographie post-quantique.

Cette cadence de sorties illustre un changement de rythme pour un projet longtemps critiqué pour sa lenteur. Entre la fin de vie de la 3.0, l’arrivée de la 4.0 en avril 2026 et l’alpha de la 4.1 cinq mois plus tard, OpenSSL a publié plus de versions majeures en dix-huit mois qu’au cours des cinq années précédentes. Pour une équipe d’infrastructure, cela signifie une fenêtre de test plus courte entre deux migrations obligatoires, mais aussi un accès plus rapide aux optimisations post-quantiques à mesure qu’elles sortent des laboratoires de recherche.

BoringSSL, le fork que Google ne veut pas voir circuler

BoringSSL est né d’un fork d’OpenSSL réalisé par Google pour ses propres besoins internes : Chrome, ChromeOS et l’infrastructure serveur de Google s’appuient dessus. Le projet ne publie pas de numéros de version au sens classique. Chaque changement est un commit sur le dépôt public, sans cycle de release ni garantie de stabilité d’API dans le temps, une différence structurelle majeure avec OpenSSL et wolfSSL.

Cette absence de gouvernance externe n’est pas un oubli, c’est un choix assumé du projet, documenté sur son dépôt GitHub officiel : BoringSSL n’est pas conçu pour un usage tiers généraliste et ne fournit aucune garantie de support en dehors de Google. Malgré cela, BoringSSL a essaimé bien au-delà de Chrome. AWS-LC, la bibliothèque cryptographique maison d’Amazon Web Services, en est directement dérivée. Cloudflare l’utilise aussi en interne : sa documentation technique sur le post-quantique montre l’outil bssl client servant à tester des connexions hybrides avec le groupe X25519MLKEM768 vers les serveurs d’origine.

Sur le volet post-quantique, Cloudflare documente également l’usage de certificats client ML-DSA lors de l’authentification mutuelle (mTLS) entre ses serveurs et les origines des clients, pour ce que l’entreprise appelle les Authenticated Origin Pulls. Cela confirme que la variante de BoringSSL utilisée en production chez Cloudflare gère à la fois l’échange de clés hybride et la signature post-quantique, même si le projet ne communique pas de feuille de route publique aussi détaillée que celle d’OpenSSL.

wolfSSL, la bibliothèque taillée pour l’embarqué

wolfSSL vise un public différent : les fabricants de microcontrôleurs, l’automobile, le médical connecté et l’industrie qui ont besoin de TLS sur du matériel avec quelques dizaines de kilo-octets de mémoire disponible. Le projet revendique une empreinte binaire minimale de 20 à 100 Ko selon les options de compilation, avec un usage RAM par connexion compris entre 1 et 36 Ko, des chiffres repris de façon constante dans sa documentation officielle depuis plusieurs années.

Côté post-quantique, wolfSSL a annoncé son premier support de ML-KEM et ML-DSA dès l’automne 2024, peu après leur normalisation par le NIST. Ce support s’est ensuite densifié : la version 5.8.4 a amélioré les implémentations de ML-KEM et ML-DSA, et la 5.9.2, sortie le 23 juin 2026, a achevé la bascule vers des implémentations nativement conformes FIPS, en abandonnant les dépendances externes liboqs, liblms et libxmss au profit du code wolfCrypt maison pour ML-KEM, ML-DSA, SLH-DSA, LMS et XMSS.

wolfSSL fonctionne sous double licence : GPLv3 pour un usage open source, ou licence commerciale pour les intégrations propriétaires. C’est ce modèle économique qui finance le développement dédié à l’embarqué, un terrain que ni OpenSSL ni BoringSSL n’adressent avec la même priorité.

Le projet publie aussi ses propres outils périphériques taillés pour l’embarqué post-quantique. Son module wolfCOSE, conçu pour les échanges de messages signés sur microcontrôleur, tient dans un minimum de 7,5 Ko de code compilé et grimpe à 25,6 Ko dans sa version complète avec quarante algorithmes disponibles, signature post-quantique incluse. Cette philosophie de composants minimaux et empilables se retrouve dans l’ensemble de la gamme wolfSSL, de la pile TLS complète jusqu’aux bibliothèques satellites comme wolfTPM ou wolfPKCS11, qui ont elles aussi reçu leur propre support ML-KEM et ML-DSA au cours de 2026.

Le tableau comparatif complet

Voici une synthèse des critères techniques, juridiques et sécuritaires qui distinguent les trois bibliothèques début septembre 2026.

CritèreOpenSSLBoringSSLwolfSSL
Dernière version (sept. 2026)4.0.2 stable, 4.1.0-alpha1 en devPas de version, suivi au commit Git5.9.2 (23 juin 2026)
LicenceApache License 2.0Licence permissive dérivée BSD/OpenSSLDouble licence GPLv3 ou commerciale
ML-KEM (FIPS 203)Natif depuis 3.5.0, 512/768/1024Hybride X25519MLKEM768Natif, 512/768/1024
ML-DSA (FIPS 204)Natif depuis 3.5.0, niveaux 44/65/87Certificats client mTLS chez CloudflareNatif, niveaux 44/65/87
SLH-DSA (FIPS 205)Natif, tous les jeux de paramètresNon documenté publiquementNatif, plus LMS et XMSS
Groupe hybride TLS 1.3 par défautX25519MLKEM768 depuis la 3.5X25519MLKEM768 disponibleDisponible, désactivé par défaut
Pic mémoire tas (build serveur)725,3 Ko (OpenSSL 4.0.0)Proche d’OpenSSL, non optimisé embarqué38,5 à 43,3 Ko
Empreinte binaire minimalePlusieurs mégaoctetsPlusieurs mégaoctets20 à 100 Ko (environ 60 Ko typique)
Validation FIPS 140-3Modules tiers validés séparémentAucune validation publiqueCertificats actifs #4718 et #5041
Principaux utilisateursDistributions Linux, curl, nginxChrome, Google Cloud, AWS-LC (fork)IoT, automobile, FreeRTOS, médical
CVE publiées en 2025-2026Au moins 10, dont une CVSS 9,8Pas de flux CVE public dédié7 CVE recensées (2025-2026)
Support commercial officielVia distributions (SUSE, Red Hat)Aucun, politique interne à GoogleDe 2 600 $ à 50 000 $ par an

Cryptographie post-quantique : qui supporte quoi

Les trois bibliothèques ont toutes ajouté du post-quantique, mais avec des niveaux de maturité différents. OpenSSL a été la première à livrer une implémentation native complète des trois algorithmes NIST dans une version stable grand public, ce qui explique pourquoi Cloudflare a pu écrire, dans son bilan 2025 de l’état d’internet post-quantique, que les versions récentes de la plupart des navigateurs et de nombreuses bibliothèques TLS, notamment OpenSSL, Go et les systèmes Apple récents, activent désormais X25519MLKEM768 par défaut.

wolfSSL couvre le même périmètre d’algorithmes (ML-KEM, ML-DSA, SLH-DSA) et y ajoute deux schémas de signature basés sur le hachage, LMS et XMSS, utiles pour les environnements qui exigent une sécurité prouvable sans hypothèse sur la difficulté d’un problème mathématique. La bascule vers des noms d’API conformes aux normes FIPS, effectuée dans la version 5.9.2, montre que le projet traite désormais le post-quantique comme un pilier natif et non plus comme un module expérimental optionnel.

BoringSSL, en comparaison, communique peu sur sa feuille de route post-quantique. Ce que l’on sait provient essentiellement de la documentation de ses utilisateurs, Cloudflare en tête, plutôt que de Google lui-même. C’est un signal important pour toute équipe qui devrait justifier sa conformité post-quantique face à un auditeur ou un régulateur : la traçabilité documentaire d’OpenSSL et de wolfSSL est nettement supérieure.

Les tailles de clés ML-KEM-768 et ML-DSA-65

Les spécifications FIPS 203 et FIPS 204 du NIST fixent des tailles fixes indépendantes de l’implémentation. Pour ML-KEM-768, le paramétrage le plus couramment déployé, la clé publique pèse 1184 octets, la clé privée étendue 2400 octets, le texte chiffré 1088 octets et le secret partagé final 32 octets. Pour ML-DSA-65, la clé publique fait 1952 octets, la clé privée 4032 octets et la signature 3309 octets. Ces chiffres expliquent le surcoût réseau observé lors des handshakes TLS hybrides : un ordre de grandeur au-dessus des clés ECC classiques, mais qui reste négligeable comparé à la bande passante d’une connexion moderne.

Le groupe hybride X25519MLKEM768, nouveau standard de facto

X25519MLKEM768 combine un échange de clés classique (X25519) avec un échange post-quantique (ML-KEM-768) : si l’un des deux venait à être cassé, la sécurité de la connexion repose encore sur l’autre. Selon les données publiées par Cloudflare, ce mode hybride ajoute environ 1,5 milliseconde de latence par rapport à un échange X25519 classique sur un trajet internet typique, un coût jugé acceptable par l’entreprise pour un déploiement à grande échelle. C’est ce même mécanisme que Google intègre à BoringSSL et qu’OpenSSL propose par défaut depuis sa version 3.5.

Benchmarks : mémoire et performance à la loupe

La documentation officielle de wolfSSL publie un comparatif d’usage mémoire particulièrement révélateur. Sur un pic de tas mesuré lors d’une session TLS, OpenSSL 3.0.0 consomme 933,3 Ko, OpenSSL 4.0.0 consomme 725,3 Ko et l’ancienne branche 1.1.1w consomme 270 Ko. Face à cela, wolfSSL 5.9.1 compilé avec l’option --enable-opensslextra consomme 43,3 Ko, et la variante optimisée en mathématiques SP descend à 38,5 Ko. L’écart entre OpenSSL 4.0.0 et wolfSSL en configuration minimale atteint donc un facteur proche de 19, ce qui confirme pourquoi wolfSSL reste le choix par défaut sur microcontrôleur.

Une étude académique publiée dans les actes du congrès brésilien SBSeg confirme cet ordre de grandeur de façon indépendante : les chercheurs ont mesuré une empreinte de 23 Ko pour wolfSSL contre plus de trente fois cette valeur pour OpenSSL sur le même scénario de test, et notent que la modularité de wolfSSL permet de descendre jusqu’à une fourchette de 20 à 100 Ko selon les fonctionnalités activées, la rendant jusqu’à 20 fois plus légère qu’OpenSSL dans certaines configurations.

Ces deux mesures indépendantes, celle de wolfSSL et celle des chercheurs brésiliens, ne tombent pas exactement sur le même chiffre, un écart normal puisque le résultat dépend fortement des options de compilation retenues (algorithmes activés, taille des tampons d’entrée-sortie, présence ou non du post-quantique). Mais elles convergent sur un ordre de grandeur commun : un facteur compris entre 15 et 30 selon la configuration, largement suffisant pour trancher le choix d’une bibliothèque sur un projet embarqué où chaque kilo-octet de RAM compte.

Sur le plan de la vitesse pure, l’écart se resserre nettement. Le coût du calcul ML-KEM-768 lui-même reste comparable d’une implémentation à l’autre puisque les trois bibliothèques s’appuient sur des primitives mathématiques identiques normalisées par le NIST. La vraie différence de performance se joue donc sur la latence réseau induite par la taille des clés, mesurée à environ 1,5 ms de surcoût par Cloudflare, et sur l’empreinte mémoire, où wolfSSL conserve un avantage structurel écrasant sur du matériel contraint. Sur un serveur cloud classique avec plusieurs gigaoctets de RAM, cet avantage devient largement anecdotique.

Le bilan des failles CVE en 2025 et 2026

OpenSSL a connu une salve de correctifs le 27 janvier 2026, avec la publication simultanée des versions 3.6.1, 3.5.5, 3.4.4, 3.3.6, 3.0.19, 1.1.1ze et 1.0.2zn. La faille la plus sévère de ce lot, CVE-2025-15467, est un dépassement de tampon sur la pile lors de l’analyse de structures CMS AuthEnvelopedData, avec un score CVSS de 9,8. Elle touche les branches 3.0, 3.3, 3.4, 3.5 et 3.6, ce qui représente une large part du parc installé. La même livraison corrige neuf autres CVE, dont une validation incorrecte des paramètres PBMAC1 dans PKCS#12 (CVE-2025-11187) et un déréférencement de pointeur nul dans SSL_CIPHER_find() (CVE-2025-15468).

wolfSSL a publié sept CVE distinctes sur la période 2025-2026. Deux d’entre elles concernent directement la couche TLS 1.3 : CVE-2025-11934 permet un déclassement de l’algorithme de signature lors de la négociation CertificateVerify sur les versions antérieures ou égales à 5.8.2, et CVE-2025-11936 autorise un déni de service via des entrées KeyShareEntry dupliquées dans un ClientHello forgé. Les autres failles touchent la couche de compatibilité OpenSSL de wolfSSL (CVE-2025-7394, génération de nombres aléatoires prévisibles après un fork), la validation de certificat sur plateformes Apple (CVE-2025-7395) et un canal auxiliaire sur les opérations Curve25519 (CVE-2025-7396). wolfSSL classe la majorité de ces failles en sévérité faible dans sa propre documentation de sécurité.

BoringSSL ne publie pas de flux CVE structuré comparable à celui d’OpenSSL ou de wolfSSL. Les correctifs remontent au fil de l’eau via les commits publics du dépôt, sans bulletin de sécurité formel systématique. Ce choix découle directement du positionnement du projet, pensé pour un usage interne chez Google plutôt que pour une consommation externe encadrée par des garanties de divulgation responsable.

Pour une équipe de sécurité qui doit produire un inventaire de vulnérabilités pour son comité de risque, cette différence de traitement change concrètement le travail à fournir. Avec OpenSSL ou wolfSSL, il suffit de suivre les identifiants CVE publiés et de vérifier la version installée contre la liste des versions corrigées. Avec BoringSSL, il faut suivre l’historique des commits du dépôt ou s’appuyer sur les correctifs déjà intégrés par l’éditeur qui fournit la variante utilisée, que ce soit Google Chrome, Cloudflare ou AWS via AWS-LC, ce qui ajoute une étape de vérification supplémentaire à chaque cycle d’audit.

Licences et tarifs : gratuit ne veut pas dire sans coût

Les trois bibliothèques sont disponibles gratuitement, mais leurs modèles de licence et de support divergent fortement dès qu’un produit commercial entre en jeu.

BibliothèqueUsage open sourceLicence commercialeSupport annuel
OpenSSLGratuit, Apache License 2.0Non applicableVia distributions tierces (SUSE, Red Hat), tarifs variables selon contrat
BoringSSLGratuit, licence permissiveNon proposée par GoogleAucun canal de support officiel externe
wolfSSLGratuit sous GPLv37 500 $ par produit ou SKU, distribution royalty-free illimitéeBasic 2 600 $, Standard 8 500 $, Premium 28 500 $, 24/7 et LTS 50 000 $ par an

La licence Apache 2.0 d’OpenSSL autorise un usage commercial sans redevance, ce qui explique sa présence par défaut dans la quasi-totalité des distributions Linux. Le support payant existe, mais il transite par des tiers, éditeurs de distributions comme SUSE ou consultants spécialisés, plutôt que par le projet OpenSSL lui-même.

wolfSSL inverse la logique : le code GPLv3 est gratuit, mais toute intégration dans un produit propriétaire non-GPL nécessite une licence commerciale à 7 500 dollars par produit ou par référence (SKU), avec droit de distribution illimité sans redevance additionnelle. Les forfaits de support annuel, allant de 2 600 à 50 000 dollars, ciblent les industriels qui ont besoin d’une astreinte 24 heures sur 24 pour du matériel critique.

BoringSSL reste hors marché : Google ne vend ni licence ni support à des tiers, et le projet le rappelle explicitement sur son dépôt public. Les organisations qui l’utilisent en production, comme Cloudflare ou Amazon via AWS-LC, assument elles-mêmes la maintenance et l’intégration.

FIPS 140-3 : qui peut vendre à l’État

La validation FIPS 140-3 conditionne l’accès à de nombreux marchés publics et industriels, notamment aux États-Unis et dans les secteurs réglementés en Europe. wolfSSL affiche ici une avance nette : le module wolfCrypt détient deux certificats actifs, le numéro 4718, valide jusqu’au 10 juillet 2029, et le numéro 5041, valide jusqu’au 17 juillet 2030, ce dernier couvrant les mêmes algorithmes que le précédent. Le projet maintient aussi la compatibilité historique avec son ancien certificat FIPS 140-2 numéro 3389 pour les déploiements qui n’ont pas encore basculé.

OpenSSL n’a pas de validation FIPS 140-3 portée par le projet central lui-même. Des modules tiers dérivés d’OpenSSL existent et obtiennent leurs propres validations séparées, un chemin plus complexe pour les équipes qui doivent démontrer leur conformité à un auditeur. BoringSSL, de son côté, ne publie aucune validation FIPS 140-3 destinée à un usage externe, cohérent avec son statut de projet interne.

Pour toute organisation soumise à un cahier des charges FIPS strict, ce critère à lui seul peut trancher le choix, indépendamment des performances ou du prix.

Le point de vue français : ANSSI et courbes de référence

Pour une organisation française, le choix d’une bibliothèque ne se limite pas au trio ML-KEM, ML-DSA, SLH-DSA. L’ANSSI publie son propre guide de sélection d’algorithmes cryptographiques, qui recommande un ensemble de courbes elliptiques classiques à utiliser en complément du post-quantique pendant la période de transition : les courbes Brainpool P256r1, P384r1 et P512r1, les courbes NIST P-256, P-384 et P-521, ainsi que Curve25519 et Curve448. Cette liste s’applique aussi bien à OpenSSL qu’à BoringSSL ou wolfSSL, puisque les trois bibliothèques implémentent ces courbes.

La différence pratique se joue sur la facilité à documenter cette conformité lors d’un audit. OpenSSL et wolfSSL publient tous deux des listes exhaustives de courbes et d’algorithmes supportés, avec les options de configuration associées, ce qui facilite grandement la production d’un dossier de preuve. BoringSSL, en l’absence de documentation officielle aussi détaillée, oblige les équipes françaises à documenter elles-mêmes la configuration réellement déployée, un travail supplémentaire qui pèse dans la balance pour tout projet soumis à une obligation réglementaire nationale.

Cinq cas d’usage réels, cinq choix différents

Les choix d’implémentation des grands acteurs du secteur illustrent bien à quel point ces trois bibliothèques répondent à des besoins distincts plutôt qu’à un même problème résolu de façons interchangeables.

  • Google Chrome et l’infrastructure serveur de Google tournent sur BoringSSL, développé et maintenu en interne pour les besoins spécifiques du navigateur et des services Google.
  • Amazon Web Services a créé AWS-LC en forkant BoringSSL, preuve que le code de Google circule bien au-delà de son usage d’origine malgré l’absence de support officiel.
  • Cloudflare combine les deux mondes : elle s’appuie sur BoringSSL pour tester ses connexions hybrides ML-KEM et sur des certificats client ML-DSA pour l’authentification mutuelle avec les serveurs d’origine de ses clients.
  • Les distributions Linux d’entreprise comme SUSE Linux Enterprise embarquent OpenSSL avec le jeu complet ML-KEM, ML-DSA, SLH-DSA et le groupe hybride x25519mlkem768 activé, pour offrir une conformité post-quantique prête à l’emploi aux entreprises clientes.
  • Les fabricants d’objets connectés et l’automobile choisissent très majoritairement wolfSSL pour sa capacité à tourner sur des microcontrôleurs avec 1 à 36 Ko de RAM disponibles, une contrainte que ni OpenSSL ni BoringSSL n’adressent nativement.

Ce panorama montre que la question “quelle est la meilleure bibliothèque” n’a pas de réponse unique. Un ingénieur qui travaillerait chez Google choisirait BoringSSL sans hésiter, parce que l’écosystème interne (outillage, revue de code, tests de non-régression) est calibré pour ce projet précis. Le même ingénieur, en freelance sur un projet de capteur agricole connecté, recommanderait wolfSSL sans hésiter davantage, parce que la contrainte mémoire du microcontrôleur rend OpenSSL simplement inutilisable. Le contexte de déploiement pèse plus lourd que n’importe quel benchmark générique.

Guide de migration vers une pile post-quantique

Pour une équipe qui exploite déjà OpenSSL et souhaite activer le post-quantique sans réécrire son code applicatif, la marche à suivre tient en quelques étapes concrètes.

  1. Vérifier la version installée avec openssl version : toute version antérieure à 3.5.0 ne propose pas ML-KEM nativement.
  2. Migrer vers la branche 3.5 (LTS, maintenue jusqu’en avril 2030) ou vers la branche 4.0 si le projet a besoin des dernières fonctionnalités TLS.
  3. Confirmer que le groupe hybride est actif par défaut, ou le forcer explicitement lors d’un test de connexion.
  4. Tester la négociation réelle avec un serveur compatible avant de basculer en production.
  5. Auditer les dépendances qui appellent directement l’API OpenSSL bas niveau, car certaines fonctions historiques changent de comportement entre les branches 3.x et 4.x.
  6. Documenter la configuration pour les futurs audits ANSSI ou eIDAS 2.0, en gardant une trace de la date d’activation du post-quantique.
openssl s_client -connect example.com:443 -groups X25519MLKEM768 -tls1_3

Pour une équipe embarquée qui part de wolfSSL, la migration passe par la recompilation avec les bons drapeaux de configuration, avant d’activer les suites correspondantes côté application.

./configure --enable-mlkem --enable-mldsa --enable-tls13
make && sudo make install

Dans les deux cas, la meilleure pratique consiste à activer le mode hybride plutôt que le post-quantique pur : en cas de faiblesse imprévue découverte dans ML-KEM ou ML-DSA, la composante classique (X25519 ou ECDSA) continue de protéger la connexion, une précaution que recommandent aussi bien OpenSSL que Cloudflare dans leur documentation respective.

Avantages et inconvénients de chaque bibliothèque

OpenSSL

  • Support post-quantique natif le plus complet et le mieux documenté des trois
  • Licence Apache 2.0 sans ambiguïté pour un usage commercial
  • Écosystème de support tiers large via les distributions Linux
  • Empreinte mémoire élevée, inadaptée à l’embarqué contraint
  • Historique de CVE critiques régulières qui impose une veille active

BoringSSL

  • Code éprouvé à l’échelle de Chrome et de l’infrastructure Google
  • Base solide pour des forks spécialisés comme AWS-LC
  • Aucun engagement de support ni de stabilité d’API pour les tiers
  • Documentation post-quantique éparse, dépendante des utilisateurs externes
  • Absence de flux CVE public structuré

wolfSSL

  • Empreinte mémoire jusqu’à 19 fois inférieure à OpenSSL sur les mêmes scénarios
  • Deux certificats FIPS 140-3 actifs, un avantage réel pour les marchés réglementés
  • Post-quantique nativement intégré depuis la version 5.9.2, sans dépendance externe
  • Licence commerciale payante dès qu’un produit propriétaire est concerné
  • Écosystème plus restreint hors embarqué et IoT

Ce que disent les équipes derrière ces projets

Le projet Open Quantum Safe, qui documente les intégrations post-quantiques dans les principales bibliothèques TLS, décrit ainsi son travail sur OpenSSL et BoringSSL : “We’ve integrated liboqs into forks of BoringSSL and OpenSSL1.1.1 as well as a standalone OQS provider for OpenSSL3 to provide prototype post-quantum key exchange and authentication and ciphersuites in the TLS protocol” (traduction : nous avons intégré liboqs à des forks de BoringSSL et d’OpenSSL 1.1.1, ainsi qu’à un provider OQS autonome pour OpenSSL 3, afin de fournir un prototype d’échange de clés et d’authentification post-quantiques dans le protocole TLS), selon la documentation TLS d’Open Quantum Safe.

Sur le fork BoringSSL spécifiquement, la même équipe précise : “Our BoringSSL fork implements post-quantum and hybrid key exchange and post-quantum public key authentication in TLS 1.3” (traduction : notre fork de BoringSSL met en œuvre l’échange de clés post-quantique et hybride, ainsi que l’authentification à clé publique post-quantique dans TLS 1.3), toujours selon la documentation d’Open Quantum Safe.

Côté wolfSSL, la documentation officielle du projet résume l’ancienneté de son engagement post-quantique : “A while back, the wolfSSL team integrated experimental post-quantum cryptographic algorithms into the wolfSSL library” (traduction : il y a quelque temps déjà, l’équipe wolfSSL a intégré des algorithmes cryptographiques post-quantiques expérimentaux à la bibliothèque wolfSSL), d’après le manuel wolfSSL.

Enfin, OpenSSL Corporation, qui accompagne les entreprises dans leur migration post-quantique sur la base d’OpenSSL, résume le changement de comportement par défaut en une phrase : “TLS now defaults to hybrid post-quantum key exchange (X25519MLKEM768), so connections gain post-quantum protection with no application changes” (traduction : TLS utilise désormais par défaut l’échange de clés hybride post-quantique X25519MLKEM768, ce qui permet aux connexions de bénéficier d’une protection post-quantique sans modification applicative), selon la page dédiée d’OpenSSL Corporation.

Le verdict : quelle bibliothèque pour quel projet

Aucune des trois bibliothèques ne domine sur tous les critères à la fois, ce qui rend le choix dépendant du contexte plutôt que d’un score global. OpenSSL s’impose par défaut pour toute application serveur classique, grâce à sa documentation post-quantique la plus complète, sa licence permissive et son intégration native dans l’écosystème Linux. Comme le confirme notre analyse d’une faille wolfSSL touchant ML-KEM, aucune bibliothèque n’est à l’abri d’un bug post-quantique, ce qui renforce l’intérêt de choisir un projet doté d’un processus de divulgation transparent.

  • Application web ou API grand public sur Linux : OpenSSL 3.5 ou 4.0, avec le groupe hybride activé par défaut
  • Navigateur ou infrastructure interne calquée sur le modèle Google : BoringSSL, en acceptant l’absence de support externe
  • Objet connecté, capteur industriel ou dispositif médical avec mémoire contrainte : wolfSSL, pour son empreinte 19 fois inférieure
  • Produit devant répondre à un cahier des charges FIPS 140-3 strict : wolfSSL, seul des trois à afficher des certificats actifs
  • Service cloud ou CDN à très grande échelle cherchant à répliquer l’approche Cloudflare : BoringSSL associé à des certificats ML-DSA pour le mTLS
  • Organisation française ou européenne visant la conformité ANSSI et eIDAS 2.0 : OpenSSL 3.5 ou supérieur, pour sa documentation de conformité la plus exploitable en audit

Sur la seule donnée chiffrée qui synthétise le mieux ces trois profils, l’écart mémoire mesuré entre OpenSSL 4.0.0 et la configuration wolfSSL la plus légère atteint un facteur de 19, tandis que le retard de communication de BoringSSL sur sa feuille de route post-quantique reste, pour l’instant, son principal point faible face à des auditeurs externes.

À moyen terme, les trois projets devraient converger davantage sur le plan algorithmique : ML-KEM et ML-DSA sont désormais des standards NIST figés, et aucune des trois équipes n’a intérêt à s’en écarter. La vraie bataille se déplace donc vers la vitesse de correction des failles, la richesse de la documentation de conformité et le coût total de possession pour les intégrateurs, trois terrains où OpenSSL et wolfSSL avancent à visage découvert, quand BoringSSL continue de fonctionner comme un projet interne prêté à l’extérieur plutôt que comme un bien commun piloté pour des tiers.

Questions fréquentes

OpenSSL, BoringSSL et wolfSSL sont-elles compatibles entre elles ?
Oui, dans la mesure où elles implémentent toutes le protocole TLS 1.3 standard. Un client OpenSSL peut négocier une connexion post-quantique avec un serveur BoringSSL ou wolfSSL tant que les deux parties proposent le même groupe hybride, comme X25519MLKEM768.

Faut-il migrer vers OpenSSL 4.0 dès maintenant ?
Pas nécessairement. La branche 3.5 reste une LTS maintenue jusqu’en avril 2030 et inclut déjà le support post-quantique complet. La migration vers 4.0 se justifie surtout pour les nouvelles fonctionnalités TLS à venir, comme celles annoncées dans l’alpha 4.1.0.

Peut-on utiliser BoringSSL en production hors de Google ?
Techniquement oui, comme le montre le fork AWS-LC d’Amazon, mais Google ne fournit aucune garantie de stabilité d’API ni de support pour les utilisateurs tiers. Toute équipe qui s’y engage doit assumer seule la maintenance à long terme.

wolfSSL est-il gratuit pour un usage commercial ?
Seulement si le produit final reste sous licence GPLv3. Dès qu’un produit propriétaire non-GPL intègre wolfSSL, une licence commerciale à 7 500 dollars par produit ou SKU devient nécessaire, avec droit de distribution illimité.

Quelle bibliothèque choisir pour respecter l’échéance ANSSI de 2027 ?
OpenSSL 3.5 ou supérieur offre la documentation de conformité la plus directement exploitable pour un audit français, grâce à son support natif et bien référencé de ML-KEM, ML-DSA et SLH-DSA. wolfSSL reste une alternative solide si le projet cible aussi une validation FIPS 140-3.

Le mode hybride post-quantique ralentit-il vraiment les connexions ?
Le surcoût mesuré par Cloudflare est d’environ 1,5 milliseconde par rapport à un échange de clés classique, un impact généralement imperceptible pour l’utilisateur final sur une connexion internet standard.

Quelle bibliothèque a le moins de CVE critiques récentes ?
Sur la période 2025-2026, wolfSSL a publié sept CVE classées majoritairement en sévérité faible, contre au moins dix pour OpenSSL dont une notée CVSS 9,8. BoringSSL ne publie pas de flux CVE comparable, ce qui rend l’évaluation directe impossible.

Peut-on combiner plusieurs de ces bibliothèques dans un même système ?
Oui, c’est même une pratique courante : une entreprise peut utiliser OpenSSL côté serveurs Linux, s’appuyer indirectement sur BoringSSL via des services cloud tiers, et déployer wolfSSL sur ses capteurs IoT, tant que toutes les briques négocient un protocole TLS 1.3 compatible.