Nobody Should Be Buying Proprietary Post-Quantum Cryptography (PQC) Algorithms

Five Post-Quantum Cryptography (PQC) companies pitched me partnership deals today. By the time I finished my morning coffee, my LinkedIn inbox held five separate offers to resell, co-brand, or “strategically align” with post-quantum encryption products I had never heard of, and four of the five promised some version of the same thing: mathematically proven unbreakable cryptography.

I have spent three decades around cryptography and the phrase still stops me. Mathematically proven unbreakable. It sounds like the strongest claim a vendor could make. In practice it is the fastest way to identify a product you should never buy. Proprietary PQC algorithms, meaning ciphers designed in-house, sold under trademark, and absent from every NIST and national standard, have become a growth category, and the pitches landing in my inbox are aimed at yours next.

So let me state the rule as plainly as I can, because the rest of this article exists to defend it: if a post-quantum algorithm is not specified in a NIST standard or approved by a national cryptographic authority, do not buy it, do not pilot it, and do not let it near your data. No demo changes this – for cryptography, demos are not how it is validated. No patent changes this – patents do not mean anything for cryptography. No whitepaper dense with Greek letters changes this, and neither does any volume of buzzwords, technobabble, or superlatives about the product. An untested, unapproved algorithm makes every other claim in the deck irrelevant.

What Every Proprietary PQC Pitch Gets Wrong

Exactly one cipher in history carries a mathematical proof of unbreakability: the one-time pad. Claude Shannon supplied the proof in his 1949 paper “Communication Theory of Secrecy Systems,” and the same proof contains the catch. Perfect secrecy requires a truly random key at least as long as the message, never reused, delivered over a channel the adversary cannot touch. If you can do all of that, you did not need the cipher. The moment a vendor shortens the key, reuses it, or stretches it with a pseudorandom generator, the proof evaporates, and what remains is an ordinary stream cipher whose security is a conjecture. The brochures keep Shannon’s vocabulary anyway: “information-theoretic security” and “unconditionally secure” are claims about this specific theorem, and they die with its conditions. Every “provably unbreakable” product I have examined turns out to be one of three things: an impractical one-time pad, a one-time pad with the proof quietly amputated, or a design where “proof” is doing the work of an adjective rather than a theorem.

What proofs in serious cryptography deliver is humbler. They are reductions: arguments that breaking scheme X requires solving problem Y. The guarantee is conditional twice over. Nobody has proven that Y is hard, as the graveyard below will demonstrate, and no reduction says anything about the software that implements X, which is where many real-world breaks happen anyway. When a NIST submission team writes “security proof,” it means a reduction with stated assumptions. When a brochure writes “mathematically proven unbreakable,” it means please stop asking questions.

The deeper error is older than the marketing. Auguste Kerckhoffs wrote in 1883 that a cryptosystem must remain secure even when everything about it except the key is public. Design secrecy guarantees only one thing: that no qualified adversary has tried to break the system. Bruce Schneier compressed the rest into a sentence in his 1998 “Memo to the Amateur Cipher Designer“: anyone can invent a cipher he himself cannot break. I have had this argument with more inventors than I can count, and it always runs the same way. They cannot imagine how their cipher could be broken, so they conclude that it cannot be. But a designer’s inability to break his own design is evidence about the designer, and about nothing else. Cryptanalysis is its own discipline, practiced at world level by perhaps a few hundred people, and the inventor is the single person least equipped to attack a scheme after spending years convincing himself of its strength. Every designer in the graveyard below was just as unable to see the break coming; the breaks came anyway. “Nobody has cracked it” measures one thing only: how hard anyone has tried. For an algorithm no cryptanalyst has ever seen, the answer is not at all.

Schneier’s 1999 catalogue of snake-oil warning signs (secret algorithms, revolutionary new mathematics, absurd key lengths, pending patents, the word “unbreakable”) reads today like a transcript of my inbox, except the modern versions insert “quantum” every fourth sentence. The vocabulary mutates faster than the behavior, which is why I maintain a Quantum Snake Oil Dictionary; if a vendor’s deck promises “quantum-grade encryption,” the entry is already written.

These vendors are the supply side of what I have called the quantum panic industry. Their pitch needs you frightened of Shor’s algorithm and an eventual CRQC, and at the same time suspicious of the NIST standards built to defend against exactly that threat. Fear of the disease, distrust of the medicine, and a miracle cure in the briefcase: the structure of the con has not changed since traveling salesmen sold actual snake oil.

One more pattern deserves a name: recycled mathematics. Several of this decade’s proprietary schemes stand on foundations that cryptanalysts hollowed out before their founders entered the industry. Knapsack constructions, chaotic maps, braid groups, and Diophantine-equation systems all return periodically under fresh trademarks, usually with no acknowledgment that the family has a casualty list. Which brings me to the casualty list.

A Walk Through the Graveyard

Cryptography may be the only branch of engineering in which a product is presumed broken until a decade of motivated, failed sabotage suggests otherwise. The presumption exists because the field keeps earning it, and the record deserves a detailed walk-through, because every body in this graveyard was designed by people far more qualified than whoever wrote the pitch sitting in your inbox.

Start in 1978. Ralph Merkle and Martin Hellman, two of the founders of public-key cryptography, published the first knapsack cryptosystem a year after RSA appeared. Merkle was confident enough to attach a $100 bounty to the basic version. Adi Shamir collected it in 1982 with a polynomial-time attack, and at the CRYPTO ’83 conference Leonard Adleman ran the break live on an Apple II while the audience watched. Merkle then offered $1,000 for the strengthened, multiply-iterated variant; Ernest Brickell collected that one in 1985. Andrew Odlyzko’s survey of the wreckage carries the title the whole episode earned: “The Rise and Fall of Knapsack Cryptosystems.” Two bounties, both paid out by one of the most brilliant cryptographers of his generation. Designing ciphers without years of public attack produces this result even for people who helped invent the field.

Move forward to a case with a standards body attached. SFLASH was a fast multivariate signature scheme built for smartcards, evaluated for years by the European NESSIE project and selected in 2003 as one of its three recommended signature algorithms. In 2007, Dubois, Fouque, Shamir, and Stern published a practical cryptanalysis showing that an attacker holding nothing except the public key could forge a signature on any message in about one second, after a one-time precomputation lasting a few minutes. Four years of official European endorsement, undone by a single paper. Institutional selection is the best filter available and still no guarantee; what saved users was that the failure surfaced in public, in time to act.

Then came the stress test of the entire post-quantum field. NIST posted 69 first-round candidates for its PQC standardization process on December 21, 2017, submitted by teams stacked with the most cited cryptographers alive. Within three weeks, 12 of the 69 had been broken or seriously attacked. By April 2018 the count reached 21, and by the end of the round it approached 25. Roughly a third of the schemes designed by the global cryptographic elite, for the most scrutinized competition in the field’s history, failed inside the first round.

The survivors fared little better as the rounds advanced. Rainbow, a multivariate signature scheme, reached the third round as one of three signature finalists; in February 2022 Ward Beullens published “Breaking Rainbow Takes a Weekend on a Laptop,” a title meant literally. Five months later SIKE, an isogeny-based KEM whose underlying problem had been studied since 2011 and which NIST had advanced into a fourth evaluation round, fell to Castryck and Decru: key recovery for the lowest-security parameter set in about an hour on a single processor core. Eleven years of cryptanalytic attention, then gone between one conference season and the next.

NIST’s follow-up call for additional signatures repeated the lesson on schedule. The agency posted 40 first-round candidates in July 2023; schemes began falling within the first week, and by February 2024, ten of the 40 had been broken completely, with several others badly weakened. One in four, dead inside eight months, in 2023, designed by professionals with two decades of post-quantum cryptanalysis to learn from.

One more entry, and it is the one that should end every conversation with a proprietary-algorithm vendor. At least one of the schemes broken in that first round did not retire. Its designers revised the mathematics, rebranded the result, and took it to market as a commercial quantum-safe product suite. In January 2026, cryptanalysts broke the entire revised suite: practical key recovery across all four products, traced to a parameter choice that hands the scheme’s discrete logarithms to a textbook algorithm published in 1978. I am deliberately not naming the company, because the point is the pattern, and in this corner of the market the pattern repeats: a cryptanalytic break gets treated as a public-relations problem, patched around, and resold.

Now invert the lesson, because the inversion is what the graveyard is for. Every failure above was caught because the design was public. The knapsack died on a conference stage. SFLASH died in the CRYPTO proceedings. Rainbow and SIKE died on ePrint within days of their attackers hitting submit, and NIST removed them before a single production system depended on them. The process is brutal to algorithms and protective of users; that is its entire design. A proprietary algorithm is just as likely to be weak; the difference is that nobody performs the autopsy. When it falls, you get no paper, no CVE, and no migration window. You get an adversary who knows, and says nothing, for years.

The Sovereignty Caveat

The lazy version of my rule would be “NIST or nothing,” and it would be wrong. I have argued at length that nations have rational reasons to standardize their own post-quantum algorithms. Distrust of foreign standard-setters did not appear from nowhere, and cryptographic sovereignty is now a first-order policy goal from Beijing to Brussels. China’s Institute of Commercial Cryptography Standards opened a global call for post-quantum algorithms in February 2025, and leading Chinese cryptographers expect national standards within three to five years. Russia’s TC26 process has produced the Shipovnik signature and the Codiaeum KEM as candidates for future GOST standards. South Korea ran its own multi-year KpqC competition and selected HAETAE, AIMer, SMAUG-T, and NTRU+ in January 2025. The EU’s coordinated PQC roadmap leaves room for European-developed algorithms, and Germany’s BSI already recommends conservative options such as FrodoKEM and Classic McEliece alongside the NIST suite. When these national selections mature, algorithms on them satisfy my rule completely.

They satisfy it because a national standardization process and a proprietary product differ in kind, whatever the marketing implies. KpqC published every candidate specification, hosted years of open cryptanalysis, watched candidates fall to attacks mid-competition, and repaired or dropped them; one independent academic evaluation of the surviving candidates ran past 200 pages. China’s ICCS call invites worldwide submissions and, with them, worldwide attack papers. These processes import the same mechanism that makes NIST’s output trustworthy: public specifications, motivated adversaries, time, and the institutional capacity to act on bad news. A vendor’s secret cipher imports the flag and skips the mechanism.

Honesty requires a concession here: standardization confers no immunity either. Dual_EC_DRBG was a NIST-standardized random number generator that, as the Snowden documents later confirmed, carried an NSA-designed backdoor. But watch how that story ran. Microsoft researchers flagged the suspicious structure publicly at a CRYPTO rump session in 2007, the evidence accumulated in the open for six years, and NIST formally withdrew the algorithm in 2014. The public process failed in public and corrected itself in public. A backdoored or broken proprietary algorithm offers no equivalent path: nobody outside the company has the access to find the flaw, and nobody inside has the incentive to announce it.

So the rule, restated with the nuance it needs: a NIST FIPS standard, your national cryptographic authority’s approved list, or a foreign national process with equivalent transparency. What does not qualify: “developed with researchers from University X,” “patented,” “ISO submission in progress,” “quantum-safe certified” by a laboratory the vendor paid, or “based on NIST finalists,” a phrase whose entire function is to make “inspired by” sound like “is.”

The One-Afternoon Verification Test

None of this requires a cryptographer on staff. It requires a browser, an afternoon, and a willingness to let the answers end a sales conversation. The procedure I give clients:

1. Ask for the algorithm’s name and its complete public specification. If the answer involves the words proprietary, patent-pending, or trade secret, stop; the evaluation is over, on the authority of a test written in 1883.
2. Check the NIST list. The standardized algorithms are ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), with FN-DSA (FALCON) still in preparation, HQC selected in March 2025 as a backup KEM, and the stateful hash-based signatures LMS and XMSS approved under SP 800-208. If the vendor’s algorithm is on this list, you have an implementation question instead, which is legitimate and covered below.
3. Check your national authority: Germany’s BSI technical guidelines, France’s ANSSI, the UK’s NCSC, CNSA 2.0 for U.S. national security systems, Japan’s CRYPTREC, South Korea’s KpqC selections, and China’s ICCS results once published. I track who requires what, and by when; none of these authorities has ever approved a vendor’s secret cipher.
4. Search the IACR Cryptology ePrint Archive for the scheme’s name. Real algorithms leave a paper trail: design documents, attack papers, parameter updates. Total silence means no qualified person has examined it. Attack papers mean qualified people examined it, and you should read what they concluded.
5. Search the NIST pqc-forum archives. The mailing list is where the world’s cryptanalysts dismantle new schemes in public, often within days of submission. If the algorithm ever passed through a NIST process, the forum thread is the due-diligence file the vendor forgot to attach.
6. Put three questions to the vendor in writing. Which standardization process was this submitted to, and what was the outcome? Where is the independent cryptanalysis of the algorithm itself, as opposed to a penetration test of the application? Which hard problem does security reduce to, and in which model? Patents, awards, and the phrase “military-grade” are not hard problems.
7. Read certifications for what they cover. FIPS 140-3 validates a cryptographic module running NIST-approved algorithms; it cannot bless a proprietary cipher, which can only execute in a non-approved mode the certificate does not vouch for. When a vendor waves a FIPS certificate over homebrew mathematics, look the certificate up in NIST’s CMVP database and check which algorithms it lists.

If the product fails steps one through three, you are finished, whatever steps four through seven might add. Years of hostile public cryptanalysis are the product. Everything else is packaging.

The Answers You Get Instead

Run the afternoon test on a proprietary-algorithm vendor and you will rarely get answers. You will get deflections, predictable enough that I have catalogued sixteen of them in a separate field guide. The organizing principle of that guide fits in one line: a legitimate company answers a technical question with a technical answer, and a questionable company answers it with anything else. Five of the anything-elses recur so reliably that they belong in this article too.

The opening move is usually the Galileo gambit: the cryptographic establishment fears new ideas and shuts out independent inventors. The field’s incentives run in the opposite direction. Careers and prizes in cryptography are made by breaking things and by proposing designs that survive the breaking, and NIST’s signature onramp accepted 40 submissions from anyone on earth willing to publish a specification. What the establishment rejects is the refusal to be tested. Galileo published.

If that fails, the story darkens into conspiracy: the firm is being suppressed because it refused to build a government backdoor into its product. Set aside the absence of evidence and look at the logic. The community supposedly doing the suppressing is the same one that spent six years publicly dismantling an actual NSA backdoor in an actual NIST standard, then forced its withdrawal. Open cryptanalysis is the worst suppression machine ever built; it publishes everything it finds. A strong algorithm cannot be held down. Post the specification on ePrint and the record will speak.

Next come credentials: the chief cryptographer’s titles, the awards, the advisory board, the papers in journals you have never heard of. Credentials are real things, and they are beside the point, because the graveyard above holds the best credentials in the field. Merkle and Hellman helped invent public-key cryptography. The Rainbow and SIKE teams were world class. If reputation cannot protect an algorithm that has been reviewed, it protects nothing about an algorithm that has not.

When credentials fail, expect technobabble overload: a wall of jargon meant to establish that you are not competent to evaluate the mathematics. Concede the point cheerfully, because it cuts against the vendor. Neither you nor I nor anyone else in that meeting can evaluate a cipher across a conference table, and that is precisely why standardization processes exist: they put the few hundred people who can evaluate one to work in public, over years. A vendor trying to win the argument in your boardroom is asking you to substitute a sales meeting for the scientific record.

The last refuge is social proof: a famous bank or a defense ministry is already a client. The claim is usually unverifiable, conveniently shielded by NDA, and often inflated from a junior analyst’s exploratory call into a production deployment. It would also be irrelevant if true. Other buyers’ due-diligence failures are not your due diligence, and sophisticated institutions have been buying broken security products for as long as both have existed. Procurement is not peer review.

Every deflection in the set has the same function: moving the conversation away from the test. Your replies do not need to be clever; they need to be repetitive. Which standard. Whose cryptanalysis. Where published.

When the Pitch Comes From Your Consultant

Some of these products will reach you escorted by a trusted logo, and this part of the market I can describe from the inside, because I run a consulting firm in it. The vendors pitching your CISO also pitch firms like mine, and their partnership decks are candid about the economics: reseller margins and referral fees well above anything the established cryptography and PKI vendors offer, because margin is the only axis on which an unvetted algorithm can compete. For a boutique consultancy under revenue pressure, or an integrator chasing quarterly targets, the financial pull toward recommending the wrong product is real. Most advisors resist it. The incentive does not care how most behave; it only needs a few.

The defense is procedural, and it sits on your side of the table. Require written disclosure, in the proposal itself, of any commercial relationship between the advisor and every vendor they recommend. Then run the afternoon test on the underlying algorithm regardless of what the disclosure says, because an advisor can be honest, well-meaning, and wrong. A recommendation that cannot be traced to a NIST or national standard gets declined, whoever delivers it and however good the steak dinner was. My own policy at Applied Quantum fits in a sentence: we recommend standardized algorithms, or we recommend nothing.

The Algorithm Is Only Half the Risk

Suppose a vendor clears every hurdle above: real ML-KEM, real ML-DSA, no invented mathematics anywhere in the stack. You are halfway done, and the second half became harder to ignore this month. On June 1, Daniel J. Bernstein released “Exploiting ML-DSA bugs,” a paper anyone procuring post-quantum products should read before signing anything. The mathematics of ML-DSA is not in question; Bernstein’s subject is the software, and that record is already poor. At least four vulnerabilities have been announced in Dilithium and ML-DSA implementations so far, including an identical key-compromising bug in both official implementations submitted to NIST in 2017, and two separate bugs found in 2026 in a library that had been marketed as formally verified. January 2026 also produced CVE-2026-24850, a signature-verification flaw in a widely used Rust implementation. All of this for an algorithm whose specification is public, whose test vectors are official, and whose implementers rank among the most capable in the industry.

Bernstein then demonstrates why the bug count matters. He constructs two small, realistic coding mistakes, the kind a tired engineer makes while unrolling a loop, and shows that each one interoperates perfectly with correct ML-DSA, passes the standard test suites, and hands an attacker the ability to forge signatures on messages of the attacker’s choosing after one second of computation on one laptop core. The base rates behind his projections come from an empirical study of eight major cryptographic libraries that counted 312 CVEs over a decade, found new code introducing roughly 0.5 to 1.2 vulnerabilities per thousand lines added, and measured the average exploitable lifetime of a flaw at more than five years. The PQC migration is now adding thousands of lines of fresh signing and key-encapsulation code to every cryptographic library on the planet, and Bernstein’s team had already pulled secret-leaking timing behavior out of a long list of Kyber implementations with KyberSlash in 2024. The implication for buyers is blunt: for the first several years of this migration, expect a meaningful fraction of PQC implementations to ship with exploitable flaws, and choose suppliers as if that were true, because it is.

Choosing suppliers well means asking ordinary software-engineering questions that have nothing to do with quantum physics. How many years has the team shipped cryptographic code in production? Who on staff has published cryptanalysis or maintained a constant-time library? Do they build on audited implementations or write primitives from scratch? Do they validate against NIST’s ACVP test vectors, and is the module FIPS 140-3 certified for the algorithms in question? What does their CVE history look like, and how quickly did they patch? A two-year-old startup whose engineering pedigree consists of a patent application fails this test even when the algorithm on the box says ML-KEM. Track record, team depth, and software discipline are security controls, as real as the mathematics.

Then deploy in hybrid, the way browsers already handle key exchange by combining classical X25519 with ML-KEM in a single handshake. Bernstein’s paper quantifies the benefit on the signature side: across his 2027 to 2039 projections, attackers break far fewer Ed25519-plus-ML-DSA double-signed keys than solo ML-DSA keys, even years after a first quantum attack arrives for the elliptic-curve half. Hybrid deployment wrapped in real crypto-agility is the cheapest insurance available against both failure modes this article has been circling: bad mathematics and bad code.

What I Reply Now

None of this is an argument for delay. The deadlines are already set, and they come from regulators, insurers, auditors, and clients: CNSA 2.0 carries hard dates for U.S. national security systems, the EU’s coordinated roadmap wants high-risk systems migrated by 2030 and everything by 2035, the UK’s NCSC has published the same 2035 endpoint, and Harvest Now, Decrypt Later collection makes the confidentiality half of the problem retroactive whatever Q-Day turns out to be. A serious migration is a decade of inventory, prioritization, and unglamorous re-plumbing, which is exactly why none of that decade can go to mathematics no qualified adversary has tried to kill. If you want structure for the work, my open-source PQC Migration Framework and these practical first steps are free. The standardized algorithms they are built around were stress-tested by the smartest hostile audience on earth, which is the one feature no proprietary product will ever ship.

As for the five companies in my LinkedIn inbox: I considered replying to each individually. This article was faster.