Feranor

Encrypting Today for Tomorrow's Quantum Computer

Every encrypted file that leaves your systems today has two lives. The one you planned for it, and the one an attacker can plan. Copy it now, keep it, and decrypt it the day a quantum computer can break RSA and elliptic curves.

Security people call it harvest now, decrypt later. It does not need a quantum computer to start. It only needs patience.

The clock is already running

The transition has dates now. They are not far away, and the data you encrypt this year must stay confidential long after them.

• 2027 ANSSI aims at post-quantum cryptography for qualification
• 11 December 2027 every obligation of the Cyber Resilience Act applies
• End of 2030 high-risk uses migrated, in the coordinated roadmap of the EU Member States
• After 2030 ANSSI advises against purchases without post-quantum cryptography
• End of 2035 medium-risk uses migrated

ANSSI is also clear on the way there: hybridization. Post-quantum algorithms are young. Until they have the decades of scrutiny RSA and elliptic curves have, you combine both, and the protection holds as long as either one holds.

The Feranor PQC Suite

Feranor PQC Suite encrypts, decrypts, signs and verifies data with post-quantum algorithms, hybrid with classical ones, under the ANSSI profile by default. Four components on one engine:

• An SDK for .NET. in-process, for .NET 10 applications
• A command line. fpqc, for scripts, batches and the archives you already have, including those encrypted with RSA
• A sidecar. An HTTP API next to applications written in Java, Python, Node, Go or anything else
• A console. A web page for business users, which holds no key

Three rules shaped every line of it.

• Standards only. CMS messages (RFC 5652), the NIST algorithms (ML-KEM, ML-DSA, SLH-DSA), keys as SubjectPublicKeyInfo and PKCS#8. What the suite writes, another standard implementation can read.
• No homemade cryptography. Every primitive comes from the platform, OpenSSL 3.5 on Linux. My code assembles, checks and refuses. It does not invent.
• Strict on input, not only on output. A message, a key or a signature outside the profile is refused, so no correspondent can impose a weaker algorithm.

Governed like the systems I write about

A cryptography product is where ambiguity costs the most. So we built it the way my book describes. Explicit contracts, one owner per module, and nothing that cannot be traced.

• The public API is a contract. Every public member is pinned, and a change that breaks it fails the build.
• Every module has one job. The library does the cryptography; the sidecar and the console only carry it to other languages and to people.
• Everything is auditable. The sidecar keeps a hash-chained audit journal, every release ships its software bill of materials, and its checksums are signed with a post-quantum key whose fingerprint is public.

Security is not a feature you add at the end. It is a structure you refuse to compromise.

Where it stands

Version 0.9.0 is the release candidate of 1.0.0. Its public API, its formats and its algorithms are those of 1.0.0. Version 1.0.0 follows the security audit and the declaration to ANSSI.

If your organization holds data that must stay secret for ten years or more, the time to look at it is now, not in 2030.