SABLIER
BlackMesa Labs · 06/10/2026 · 84 fichiers lus · analyse en 367 ms
Le post-quantique, en trois phrases. La cryptographie qui protège aujourd'hui le web repose sur des problèmes faciles dans un sens et infaisables dans l'autre — multiplier deux grands nombres premiers est immédiat, retrouver ces facteurs demanderait des milliers d'années. Un calculateur quantique suffisamment grand rend ce retour possible : RSA et les courbes elliptiques, c'est-à-dire l'essentiel de ce qui chiffre et signe aujourd'hui, tombent d'un coup — la taille des clés n'y change rien. La cryptographie post-quantique désigne les algorithmes conçus pour résister à cette machine, normalisés en 2024 (ML-KEM pour le chiffrement, ML-DSA pour la signature) ; le chiffrement symétrique, lui, AES et ChaCha20, n'est pas menacé.
Sablier inventorie la cryptographie d'un projet et la confronte à une information qu'aucun outil ne possède : combien de temps chaque donnée doit rester confidentielle. Une donnée chiffrée aujourd'hui avec RSA ou une courbe elliptique, et qui doit rester secrète au-delà de la péremption de ces algorithmes, est déjà perdue — un adversaire capture maintenant ce qu'il déchiffrera plus tard, et la migration ne protégera que ce qui viendra après elle.

Ce rapport distingue donc ce qui se récolte (le chiffrement) de ce qui ne se récolte pas (les signatures), laisse tranquille la cryptographie symétrique, et sépare les problèmes d'aujourd'hui — MD5, SHA-1 — de l'échéance quantique.

Aucune donnée dont la durée de confidentialité dépasse la péremption des algorithmes qui la protègent.

2 constats retenus sur l'ensemble analysé. Date de péremption retenue : 2035 — c'est l'échéance réglementaire, pas une prédiction de rupture cryptographique. Échéance vérifiée auprès de ses sources le 30/09/2026.

Durée de confidentialité des données, face à la péremption des algorithmes

2030
dépréciation
2035
péremption
non déclaré
0 an

Chaque barre est la durée pendant laquelle la donnée doit rester confidentielle. Elle passe en rouge quand un algorithme récoltable la protège au-delà du trait de péremption — dépasser le trait sans être rouge signifie que la donnée dure longtemps, mais qu'elle est protégée par de la cryptographie qui tiendra.

Ce que le serveur négocie réellement

mesa.black

service
HTTPS
protocole négocié
TLSv1.3
suite
TLS_AES_128_GCM_SHA256 (128 bits)
groupe négocié
X25519MLKEM768
signature du certificat
ecdsa-with-SHA384
clé du certificat
courbe elliptique 256 bits
chaîne
4 certificats
certificat valide jusqu'au
04/01/2027
versions acceptées
TLSv1.2, TLSv1.3

Une poignée de main, pas une lecture de fichier : c'est le seul moyen de savoir ce qui protège vraiment le trafic, et cela peut contredire ce que le dépôt déclare.

SURVEILLER 1

ECDSA non déclaré

tls://mesa.black:443
ecdsa-with-SHA384 · EC-256

Signature : pas de récolte possible. À migrer avant 2030 pour la conformité, sans urgence de confidentialité. Certificat serveur. Sa durée de vie est courte : le remplacer par une signature post-quantique se fera au renouvellement, sans migration de données.

Remplacement ML-DSA
Faux positif ? empreinte 4d2a0227

Accepter ce constat : sablier accept 4d2a0227 --reason="…" --until=2027-04-06

"accepted": {
  "4d2a0227": {
    "reason": "…",
    "until": "2027-04-06"
  }
}

L'outil a tort ? Ouvrir un signalement pré-rempli

CONFORME 1

ML-KEM · 1 usage Normalisé FIPS 203.

Ce que ce rapport n'a pas regardé

Un inventaire qui ne dit pas ce qu'il n'a pas vu n'est pas un inventaire.

Ce qu'il y a à changer

1 emplacement(s) à reprendre, dans 1 fichier(s). Les lignes ci-dessous comptent des endroits, pas des semaines.

AlgorithmeAppelsFichiersDomainesCe que cela change
ECDSA111

La feuille de route européenne compte l'effort de migration parmi les trois facteurs du risque quantique. Cet outil le compte en emplacements parce que c'est ce qu'un dépôt sait dire ; il n'en fait pas une durée. Huit appels dans un fichier derrière une même fonction sont une après-midi ; huit répartis sur six services avec un protocole entre eux sont un trimestre, et rien dans les fichiers ne distingue les deux. Cette estimation vous appartient.

Ce qu'il faut faire, dans l'ordre

Un inventaire qui ne conclut rien se range dans un dossier. Voici l'arbitrage — et l'ordre compte autant que la liste.

  1. Rien d'urgent, et c'est un résultat

    Aucune donnée à longue durée n'est exposée à la récolte, et rien n'est cassé aujourd'hui. Ne rien faire est ici la bonne décision : remplacer de la cryptographie qui tient coûte du temps, introduit du risque et n'améliore rien.

  2. Remettre ce rapport au calendrier

    La fenêtre se referme d'elle-même : la date de péremption ne bouge pas (2035), mais chaque année qui passe rapproche vos données de cette ligne. Un domaine conforme aujourd'hui avec une durée de neuf ans ne le sera plus l'an prochain. Rejouer l'analyse une fois par an suffit — et vérifier à cette occasion que l'échéance réglementaire n'a pas bougé.

Envoyer le résumé sur Threema

Ouvre Threema sur un téléphone où l'application est installée. Sur un ordinateur, le schéma n'est en général pas enregistré et le navigateur refuse le lien : copiez le texte ci-dessous. Rien n'est transmis à un serveur tiers.

Voir le texte à envoyer
Sablier — inventaire cryptographique de BlackMesa Labs (06/10/2026)

Aucune donnée dont la durée de confidentialité dépasse la péremption des algorithmes qui la protègent.

2 constats retenus. Échéance de péremption retenue : 2035.
Première action : Rien d'urgent, et c'est un résultat

Faux positif ?

Deux choses s'appellent « faux positif », et elles ne vont pas au même endroit.

1. L'outil a raison, mais ce constat est accepté ici. C'est une décision de projet : ajoutez ce bloc à votre déclaration, elle est versionnée, donc la relecture se fait en revue de code. La raison et la date d'expiration sont obligatoires.

"accepted": {
  "<empreinte>": {
    "reason": "…",
    "until": "2027-04-06"
  }
}

En ligne de commande : sablier accept <empreinte> --reason="…" --until=2027-04-06

2. L'outil a tort. C'est une règle à corriger, et sa place est dans le dépôt de Sablier : github.com/mesa-black/sablier

L'empreinte imprimée à côté de chaque constat le désigne, et c'est elle qu'on cite dans les deux cas. Elle est calculée sur la preuve, pas sur le numéro de ligne : elle survit à un déplacement du code, et change le jour où la ligne change vraiment.

Empreinte et signature

empreinte des constats
8ecb829ccc278ef7ab3138f56e07ee13319cbb72ce1dabbfc58ee7b4d6b670b5
signé le
Ed25519 + ML-DSA-65 · 06/10/2026 08:34
clé publique
+B/8vbI5Wxt9GVDN…

L'empreinte porte sur les constats, pas sur ce fichier : deux rendus du même inventaire, dans deux langues, donnent la même valeur.

Ce rapport porte deux signatures : Ed25519, vérifiable partout, et ML-DSA-65, qui résiste aux algorithmes quantiques connus. Aucune ne remplace l'autre — c'est l'hybridation que l'ANSSI demande, appliquée ici au document lui-même.

Pour vérifier cette signature, avec le fichier .sig déposé à côté de ce rapport : sablier verify <rapport>.sig --declare=<déclaration>

Ce que la signature ne couvre pas : les octets de cette page. Un rapport affiche sa propre signature, donc il ne peut pas la contenir — ce qui est signé est l'empreinte des constats ci-dessus. Pour lier les deux, rejouez l'analyse sur le même état du dépôt et comparez l'empreinte obtenue : même inventaire, même valeur. Sans ce recalcul, une page modifiée à la main se vérifie quand même.

Ce que la signature établit : cette empreinte a été signée par la clé que la déclaration désigne. Ce qui rattache cette clé à quelqu'un n'est pas cette page — c'est l'historique du fichier qui la déclare, où tout changement de clé est un commit daté que n'importe qui peut relire.