Security marketing has a dialect, and learning to read it is a procurement skill. A field guide to vendor cryptography claims: which phrases carry information, which carry none, and the questions that sort one from the other.
Part 10 of 10 in Trust through mathematics
Somewhere in nearly every security product’s marketing sits the phrase “military-grade encryption”. Pause on what that phrase actually tells you. The honest answer is: that the vendor employs a marketing department. There is no military grade. The world’s militaries use, for the most part, the same published algorithms as everyone else – AES is approved for US classified information, and AES is also what encrypts your supermarket loyalty app. The algorithm has never been the differentiator. Everything around it is.
This closing post of the series is a practical one: a guide to reading vendor cryptographic claims, written from the experience of sitting on the assessing side of the table. The encouraging news, after nine posts on trust through mathematics, is that cryptographic claims are unusually checkable – provided you insist on the checkable versions of them.
Phrases That Carry Little Information
A short lexicon of statements that sound substantive and are compatible with almost anything.
“Military-grade encryption” – see above. Usually means AES-256, which is excellent and universal, and about as distinguishing as “aviation-grade aluminium” on a stepladder.
“Bank-level security” – banks are large, heterogeneous estates running everything from HSM-backed payment cryptography to mainframe applications of remarkable antiquity. The comparison is unfalsifiable, which is its purpose.
“256-bit encryption” – a key length with no algorithm, no mode, and no statement of what is encrypted, where, or against whom. The number is doing theatre.
“Data encrypted at rest and in transit” – true of effectively every cloud service, and silent on the only question this series has cared about: who holds the keys. Data encrypted at rest under provider-held keys is protected from stolen drives and from nothing else that worries you.
“Zero-knowledge architecture” – sometimes a precise claim about client-side key custody, increasingly a borrowed term applied loosely, as we noted in the zero-knowledge post. The phrase has been diluted by exactly the vendors one would predict.
“Proprietary encryption algorithm” – uniquely among these entries, informative, because it is a red flag. A century of cryptanalysis has established that algorithms earn trust only through years of public attack by people who enjoy breaking things. A secret algorithm is not an extra layer of security; it is an unreviewed one. Schneier’s law – anyone can design a cipher they themselves cannot break – remains the most useful sentence in the field.
Claims That Do Carry Information
The same product properties can be stated in verifiable form, and serious vendors increasingly do.
Named primitives and protocols are the first thing to look for. “TLS 1.3; AES-256-GCM; X25519 key agreement; the Signal protocol for messaging; Argon2id for password hashing” – claims like these are precise enough to be wrong, which is what makes them useful. A vendor who names their cryptography invites an expert to check it, and the invitation is itself evidence.
Published protocol documentation is the next. Not the brochure, but the document that would let a competent third party implement or attack the design. Its existence signals that the vendor expects, and can survive, expert readership.
Independent audits, named and published, carry more than the adjective alone. “Independently audited” is half a claim; the other half is by whom, of what scope, with findings recorded where. Reputable cryptographic audit firms publish reports that include what they found, and a vendor who commissions such work and publishes the results – including the embarrassing middle pages – is making the strongest assurance statement available short of formal verification.
Certifications repay being read precisely. FIPS 140-3 validation attests that a specific cryptographic module performs its operations correctly – a real and meaningful property – not that the product around the module is well designed. Common Criteria attests to evaluation against a stated target. Certifications are evidence about exactly what they evaluate, and never about the whole.
Key custody, stated plainly, is the tell that matters most. A serious vendor can answer “who can decrypt, under what circumstances, and what can you produce under legal compulsion?” in a single paragraph, without the words “industry-standard” appearing in it. The supply-chain post’s question – what would we see if you were compromised? – belongs here too.
And a track record under disclosure tells you more than a clean sheet. Counter-intuitively, a vendor with published CVEs and competent fixes is usually the safer bet: cryptographic software with no disclosed vulnerabilities is mostly cryptographic software nobody has examined.
Five Questions That Do The Work
For procurement, the lexicon compresses to five questions, all askable by a non-specialist and all answerable in terms a specialist can then check:
- Exactly which algorithms and protocols, by name and version?
- Who generates the keys, where do they live, and who can use them without our participation?
- What has been independently audited, by whom, and where is the report?
- What can you technically access or produce about us, under compulsion or compromise?
- What is your process when a vulnerability is found, and where is the evidence of it operating?
The pattern in the answers matters more than any single answer. Vendors with good architecture answer quickly, specifically, and in writing, because the answers are assets they have already paid for. Vendors with adjectives answer at length, generally, and on calls. We have read a great many of both kinds on clients’ behalf, and the correlation between specificity and quality is among the most reliable in the trade. The whole distance between trust by contract and trust by mathematics is visible in whether a claim is decorated or checkable.
Closing The Series
Ten posts ago we began with a simple distinction: promises that depend on conduct, and guarantees that depend on computation. In between we have looked at where the guarantee actually sits in messaging and key custody, what is arriving with post-quantum standards and zero-knowledge proofs, how silicon and signatures anchor trust in hardware and in supply chains, what encryption leaves exposed, and how the arrival of machine readers raises the price of imprecision.
The thread through all of it is one habit of mind: locate the boundary of the guarantee, and ask what lives outside it. Vendors, reasonably enough, describe the inside. The incidents, reliably, occur outside. The discipline of asking boundary questions – who holds the keys, what does the operator see, what happens when the promise fails – is not cryptographic expertise. It is due diligence of the ordinary professional kind, applied to claims that have too long enjoyed an exemption from it.
The mathematics, as we said at the start, is the easy part. It does what it says. The work is making sure that what it says is what you needed.