BlackMesa Labs · 06/10/2026 · 130 files read · analysed in 357 ms
Post-quantum, in three sentences. The cryptography protecting the web today rests on problems that are easy one way and infeasible the other — multiplying two large primes is instant, recovering those factors would take thousands of years. A large enough quantum computer makes that return trip possible: RSA and elliptic curves, which is to say most of what encrypts and signs today, fall at once — key size makes no difference. Post-quantum cryptography is the family of algorithms designed to resist that machine, standardised in 2024 (ML-KEM for encryption, ML-DSA for signatures); symmetric encryption, AES and ChaCha20, is not under threat.
Sablier inventories a project's cryptography and crosses it with something no tool knows: how long each kind of data has to stay confidential. Data encrypted today with RSA or an elliptic curve, and required to stay secret past the expiry of those algorithms, is already lost — an adversary captures now what they will decrypt later, and migration only protects what comes after it.
So this report separates what is harvestable (encryption) from what is not (signatures), leaves symmetric cryptography alone, and keeps today's problems — MD5, SHA-1 — apart from the quantum deadline.
No data whose confidentiality lifetime outlasts the expiry of the algorithms protecting it.
2 findings kept across everything analysed. Expiry date used: 2035 — that is the regulatory deadline, not a prediction of when the maths breaks. Deadline last checked against its sources on 30/09/2026.
How long data must stay confidential, against the expiry of the algorithms
{"title":"How long data must stay confidential, against the expiry of the algorithms","start":2026,"end":2046,"marks":[{"year":2030,"label":"deprecation"},{"year":2035,"label":"expiry"}],"bars":[{"name":"undeclared","years":0,"exposed":false}]}
2030 deprecation
2035 expiry
undeclared
0 year
Each bar is how long the data must stay confidential. It turns red when a harvestable algorithm protects it past the expiry line — crossing the line without turning red means the data lives long but is protected by cryptography that will hold.
What the server actually negotiates
mesa.black
service
HTTPS
negotiated protocol
TLSv1.3
cipher suite
TLS_AES_128_GCM_SHA256 (128 bits)
negotiated group
X25519MLKEM768
certificate signature
ecdsa-with-SHA384
certificate key
elliptic curve 256 bits
chain
4 certificates
certificate valid until
04/01/2027
accepted versions
TLSv1.2, TLSv1.3
A handshake, not a file read: it is the only way to know what really protects the traffic, and it can contradict what the repository declares.
WATCH 1
ECDSA undeclared
tls://mesa.black:443
ecdsa-with-SHA384 · EC-256
Signature: not harvestable. Migrate before 2030 for compliance, with no confidentiality urgency. Server certificate. Its lifetime is short: replacing it with a post-quantum signature happens at renewal, with no data migration.
Replacement ML-DSA
False positive? fingerprint 4d2a0227
Accept this finding: sablier accept 4d2a0227 --reason="…" --until=2027-04-06
the cryptography of your managed services — database, object storage, TLS terminated by an intermediary — appears in no file of this repository
what is actually negotiated at runtime, for any host not declared in the probe section
keys held in an HSM or by a provider
the real lifetime of the data: it comes from your declaration, not from the code — an undeclared domain is computed with a default lifetime of 0 years
The system's service horizon is not declared: the calculation assumes it stops writing data today. That is the optimistic reading — a service still in production in ten years will produce ten more years of data to protect. Add `service_until` to the declaration.
Expiry used: 2035, after NIST IR 8547. Another regime — institutional, defence — gives another date: see `regime` in the declaration.
Binary files (images, fonts, archives) are read over their first few megabytes only, and only for three verifiable signs: a key block, bytes after the end of the image, an extension that lies about the content. A message hidden in the bits of an image is not detected here, and does not claim to be.
Published vulnerabilities in dependencies were not checked: run `sablier advisories <path>`, then `--advisories=<file>`. Without it, a library with a hole in it today is presented as plain inventory.
An inventory that does not say what it failed to look at is not an inventory.
What there is to change
1 place(s) to revisit, across 1 file(s). The rows below count places, not weeks.
Algorithm
Call sites
Files
Domains
What that changes
ECDSA
1
1
1
The EU roadmap counts the migration effort among the three factors of quantum risk. This tool counts it in places, because that is what a repository can tell; it does not turn that into a duration. Eight call sites in one file behind one function are an afternoon; eight across six services with a protocol between them are a quarter, and nothing in the files distinguishes the two. That estimate is yours.
What to do, in order
An inventory that concludes nothing gets filed away. Here is the arbitration — and the order matters as much as the list.
Nothing urgent, and that is a result
No long-lived data is exposed to harvesting, and nothing is broken today. Doing nothing is the right decision here: replacing cryptography that holds costs time, introduces risk and improves nothing.
Put this report back on the calendar
The window closes by itself: the expiry date does not move (2035), but every year that passes brings your data closer to that line. A domain that is clear today with a nine-year lifetime will not be next year. Re-running the analysis once a year is enough — and checking, while you are there, that the regulatory deadline has not moved.
Opens Threema on a phone where the app is installed. On a desktop the scheme is usually not registered and the browser refuses the link: copy the text below instead. Nothing is sent to a third party.
Show the text it would send
Sablier — cryptographic inventory of BlackMesa Labs (06/10/2026)
No data whose confidentiality lifetime outlasts the expiry of the algorithms protecting it.
2 findings kept. Expiry date used: 2035.
First action: Nothing urgent, and that is a result
False positive?
Two different things get called a false positive, and they do not go to the same place.
1. The tool is right, but this finding is accepted here. That is a project decision: add this block to your declaration. It is versioned, so the review happens in code review. A reason and an expiry date are both required.
On the command line: sablier accept <fingerprint> --reason="…" --until=2027-04-06
2. The tool is wrong. That is a rule to fix, and it belongs in Sablier's own repository: github.com/mesa-black/sablier
The fingerprint printed next to each finding identifies it, and it is what you quote in either case. It is computed from the evidence rather than the line number: it survives the code moving, and it changes the day the line materially changes.
The digest covers the findings, not this file: two renderings of the same inventory, in two languages, give the same value.
This report carries two signatures: Ed25519, verifiable anywhere, and ML-DSA-65, which resists the known quantum algorithms. Neither replaces the other — it is the hybridation ANSSI asks for, applied to the document itself.
To check this signature, with the .sig file filed beside this report: sablier verify <report>.sig --declare=<declaration>
What the timestamp establishes: the digest above existed on that date, according to a third party with no stake in these conclusions. No signature on this report can prove that, because the date it carries comes from the clock of the machine that signed. Its limit: the token is signed with RSA-4096, which this report itself classes as quantum vulnerable — it is evidence for a dispute in the next few years, not for 2040.
The date is checked without this tool, with the token filed beside the report: openssl ts -verify -digest <digest> -in <report>.tsr -CAfile <authority root>
What the signature does not cover: the bytes of this page. A report displays its own signature, so it cannot contain it — what is signed is the digest of the findings above. To tie the two together, replay the analysis on the same state of the repository and compare the digest you get: same inventory, same value. Without that recomputation, a page edited by hand still verifies.
What the signature establishes: that digest was signed by the key the declaration designates. What ties that key to somebody is not this page — it is the history of the file that declares it, where any change of key is a dated commit anybody can read.