liboqs rassemble des implémentations de mécanismes d’encapsulation de clé (OQS_KEM) et de schémas de signature (OQS_SIG) post-quantiques derrière une seule API C, et c’est le moteur du fournisseur Open Quantum Safe pour OpenSSL 3. Les faits présentés ici ont été vérifiés sur la version 0.16.0 (commit 5a1a854b0dc9), compilée avec les options CMake par défaut, qui utilisent OpenSSL pour les primitives symétriques. Le README avertit, en majuscules : « NOUS NE RECOMMANDONS PAS ACTUELLEMENT DE S’APPUYER SUR CETTE BIBLIOTHÈQUE DANS UN ENVIRONNEMENT DE PRODUCTION NI POUR PROTÉGER LA MOINDRE DONNÉE SENSIBLE. » Pour ML-KEM et ML-DSA en production, les pages OpenSSL, BoringSSL, AWS-LC et Bouncy Castle indiquent ce que proposent leurs API principales.
Le build par défaut a activé 41 KEM et 221 jeux de paramètres de signature, et un jeu de paramètres de chaque famille a effectué un aller-retour complet : les normes NIST ML-KEM, ML-DSA et SLH-DSA (156 variantes SLH-DSA, pures et avec pré-hachage), Falcon, les candidats KEM HQC, Classic McEliece, FrodoKEM, BIKE, NTRU et sntrup761, Kyber dans sa version antérieure à la normalisation, ainsi que les candidats de signature supplémentaires MAYO, CROSS, UOV, SNOVA et MQOM. Dans du nouveau code, nommez ML-KEM-768, et non Kyber768. Aucun jeu de paramètres XMSS ou LMS n’est activé dans le build par défaut.
La signature ML-DSA est en mode hedged (avec aléa) : deux signatures du même message avec la même clé différaient, si bien que les tests doivent vérifier les signatures plutôt que comparer des octets. Les chaînes de contexte de FIPS 204 sont prises en charge via OQS_SIG_sign_with_ctx_str ; une signature produite sous le contexte invoice-v1 a échoué sous invoice-v2 et avec le simple OQS_SIG_verify, qui utilise le contexte vide, ce qui oblige les deux parties à s’accorder sur ce contexte. Une signature tronquée, un bloc de 3 octets et une signature valide portant sur d’autres données ont tous renvoyé le même OQS_ERROR.
La décapsulation ML-KEM ne signale pas un texte chiffré endommagé : avec un bit inversé, OQS_KEM_decaps a renvoyé OQS_SUCCESS et un secret partagé différent, comme l’exige le rejet implicite de FIPS 203. La divergence n’apparaît qu’à l’utilisation des clés dérivées, par exemple sous la forme d’un échec de déchiffrement AEAD. La fonction ne prend pas non plus de longueur de texte chiffré et lit exactement length_ciphertext octets, soit 1088 pour ML-KEM-768. Essayez les deux schémas dans l’outil ML-KEM et l’outil de signatures post-quantiques.