Feranor

Chiffrer aujourd'hui pour l'ordinateur quantique de demain

Chaque fichier chiffré qui quitte vos systèmes aujourd'hui a deux vies. Celle que vous avez prévue pour lui, et celle qu'un attaquant peut prévoir. Le copier maintenant, le garder, et le déchiffrer le jour où un ordinateur quantique saura casser RSA et les courbes elliptiques.

Dans le métier, on appelle cela harvest now, decrypt later : collecter maintenant, déchiffrer plus tard. Il n'y a pas besoin d'ordinateur quantique pour commencer. Il suffit d'être patient.

Le compte à rebours a déjà commencé

La transition a désormais des dates. Elles ne sont pas loin, et les données que vous chiffrez cette année devront rester confidentielles bien après elles.

• 2027 l'ANSSI vise le post-quantique en qualification
• 11 décembre 2027 toutes les obligations du Cyber Resilience Act s'appliquent
• Fin 2030 usages à haut risque migrés, dans la feuille de route coordonnée des États membres de l'UE
• Après 2030 l'ANSSI déconseille les achats sans cryptographie post-quantique
• Fin 2035 usages à risque moyen migrés

L'ANSSI est claire aussi sur le chemin : l'hybridation. Les algorithmes post-quantiques sont jeunes. Tant qu'ils n'ont pas les décennies d'examen de RSA et des courbes elliptiques, on combine les deux, et la protection tient tant que l'un des deux tient.

La Suite Feranor PQC

Feranor PQC Suite chiffre, déchiffre, signe et vérifie des données avec des algorithmes post-quantiques, hybrides avec les algorithmes classiques, sous le profil ANSSI par défaut. Quatre composants sur un même moteur :

• Un SDK pour .NET. dans le processus, pour les applications .NET 10
• Une ligne de commande. fpqc, pour les scripts, les traitements par lots et les archives que vous avez déjà, y compris celles chiffrées en RSA
• Un sidecar. Une API HTTP à côté des applications écrites en Java, Python, Node, Go ou n'importe quoi d'autre
• Une console. Une page web pour les utilisateurs métier, qui ne détient aucune clé

Trois règles ont façonné chaque ligne.

• Uniquement des standards. Messages CMS (RFC 5652), algorithmes du NIST (ML-KEM, ML-DSA, SLH-DSA), clés SubjectPublicKeyInfo et PKCS#8. Ce que la suite écrit, une autre implémentation standard peut le lire.
• Aucune cryptographie maison. Chaque primitive vient de la plateforme, OpenSSL 3.5 sous Linux. Mon code assemble, vérifie et refuse. Il n'invente pas.
• Strict en entrée, pas seulement en sortie. Un message, une clé ou une signature hors profil est refusé, si bien qu'aucun correspondant ne peut imposer un algorithme plus faible.

Gouverné comme les systèmes sur lesquels j'écris

Un produit de cryptographie est l'endroit où l'ambiguïté coûte le plus cher. Nous l'avons donc construit comme notre livre le décrit. Des contrats explicites, un responsable par module, et rien qui ne puisse être retracé.

• L'API publique est un contrat. Chaque membre public est figé, et un changement qui la casse fait échouer le build.
• Chaque module a un seul rôle. La bibliothèque fait la cryptographie ; le sidecar et la console ne font que la porter vers d'autres langages et vers les gens.
• Tout est auditable. Le sidecar tient un journal d'audit chaîné, chaque version livre sa nomenclature logicielle, et ses empreintes sont signées avec une clé post-quantique dont l'empreinte est publique.

La sécurité n'est pas une fonction qu'on ajoute à la fin. C'est une structure sur laquelle on refuse de transiger.

Où en est-on

La version 0.9.0 est la release candidate de la 1.0.0. Son API publique, ses formats et ses algorithmes sont ceux de la 1.0.0. La 1.0.0 suivra l'audit de sécurité et la déclaration à l'ANSSI.

Si votre organisation détient des données qui doivent rester secrètes dix ans ou plus, c'est maintenant qu'il faut s'en occuper, pas en 2030.