The Questions That Catch What Code Review Misses: A Crypto Audit Guide for Non-Specialists

By the time a cryptographic mistake reaches code review, it has usually already been made twice: once in the threat model and once in the architecture document. The implementation is often the third occurrence, and it is the one that gets the most scrutiny despite being the least consequential place to catch the problem. Fixing a cipher choice in a pull request is straightforward. Fixing a cipher choice that has been embedded in a signed API contract, a hardware security module provisioning workflow, and three years of encrypted backup archives is a different category of problem entirely.

The challenge for most development teams is that security architecture reviews happen in rooms where cryptographic expertise is absent or superficial. Developers understand the systems they are building. Architects understand the integration patterns. Security generalists understand the compliance requirements. But the specific question of whether the cryptographic design choices are sound — whether the assumptions embedded in the abstraction layer hold under adversarial conditions, whether the key lifecycle has been thought through, whether the algorithm choice is appropriate for the threat model — often goes unasked because no one present knows to ask it.

This guide is not a substitute for a cryptographer. It is a structured approach to asking better questions in the absence of one.

Why Architecture Reviews Let Crypto Problems Through

The failure mode is not negligence. It is a combination of epistemic humility and the social dynamics of technical review meetings. When a developer presents a design that uses TLS for transport security, AES-256 for data at rest, and HMAC-SHA256 for message integrity, the instinct of most reviewers is to treat the cryptographic layer as resolved. The names are recognizable. The algorithms are widely used. The implementation will presumably use a reputable library.

What that framing misses is that algorithm selection is only the first question in a cryptographic design review, and usually not the most important one. The harder questions are about assumptions: What is the threat model that this design is optimized against? Who generates and holds the keys, and under what conditions? What happens when a key is compromised? How does the system behave if a signature verification fails — does it fail safely, or does it degrade to an insecure fallback? Is the cryptographic boundary drawn at the right layer of the stack, or does it leave sensitive material exposed in transit between components?

These questions do not require a cryptography PhD to ask. They require a structured habit of suspicion.

Five Dangerous Patterns to Surface in Design Reviews

The magical abstraction. This pattern appears when a design document describes cryptographic protection at a high level of abstraction without specifying the underlying mechanisms. "Data is encrypted in transit and at rest" is a magical abstraction. It defers every meaningful question — which algorithms, which key lengths, which modes of operation, which key management approach — to an implementation decision that may never be formally reviewed. When you see this pattern, the right response is not to accept the abstraction but to require it to be unpacked. Ask specifically: What cipher, what mode, what key size, and who manages the keys? The answers, or the inability to provide them, are diagnostic.

The absent threat model. Cryptographic design choices are only meaningful relative to a threat model. AES-128 in GCM mode is appropriate for many threat models and inadequate for some. RSA-2048 is adequate for certain use cases and already marginal for others given post-quantum considerations. When a design review proceeds without an explicit statement of what adversary capability the cryptographic controls are designed to defeat, the choices embedded in that design are essentially arbitrary — they may happen to be correct, but there is no principled basis for evaluating them. Ask directly: What adversary capability does this design assume, and what is the highest-privilege attack this cryptographic layer is intended to prevent?

Undocumented algorithm selection rationale. In mature cryptographic engineering practice, algorithm choices are documented with rationale — not because the documentation is intrinsically valuable, but because the act of articulating rationale forces the designer to have a rationale. When a design document lists algorithm choices without explanation, or when the designer responds to questions about rationale with "it's industry standard" or "the library defaults to it," the alarm should register. Library defaults are not threat model analysis. Ask: Why this algorithm specifically, and what would change about this design if the threat model shifted in a specific direction?

No key rotation plan. Key rotation is one of the most operationally neglected aspects of cryptographic system design, and it is almost always easier to design in from the beginning than to retrofit. When a design review covers key generation and key storage but not key rotation, expiration, and revocation, the design is incomplete in a way that will create operational problems. Ask: What is the maximum key lifetime, what triggers rotation, and what is the process for rotating a key that has been compromised rather than expired normally? If the answer involves significant downtime or manual intervention, that is a design constraint worth surfacing before implementation.

The implicit trust boundary. Many cryptographic failures occur not because an algorithm was broken but because the cryptographic boundary was drawn incorrectly — data was decrypted before being passed to a component that did not need plaintext, or a key was accessible to a process with broader privileges than the cryptographic design assumed. In architecture reviews, look for places where the diagram shows encrypted data crossing a boundary and ask: At what point is this decrypted, by what process, and what is the privilege level of that process? Implicit trust boundaries that have not been explicitly examined are a consistent source of cryptographic design failures.

A Pre-Meeting Checklist for Architecture Review Participants

The following questions are designed to be asked before the review meeting begins, based on whatever design documentation is available. Bringing specific, pre-formed questions into a review meeting is considerably more effective than attempting to formulate them in real time.

• Does the design document specify algorithms and key lengths, or does it use high-level abstractions only?
• Is there an explicit threat model, and do the cryptographic choices map to it?
• Is there a documented key lifecycle: generation, storage, rotation, expiration, and revocation?
• Does the design address what happens when a key is compromised mid-lifecycle?
• Are there any places where the design relies on "security by obscurity" — where the protection depends on an attacker not knowing something about the implementation rather than not possessing a key?
• Does the design use any non-standard cryptographic constructions, or does it compose well-understood primitives in ways that have established security proofs?
• Is there a plan for cryptographic agility — the ability to swap algorithms if a future deprecation requires it?

None of these questions require specialized expertise to ask. They require only the discipline to ask them before the design is approved.

When to Escalate

The framework above is designed for the common case: a review where no cryptographer is present but the design decisions are within the range of well-understood patterns. It is not designed for every situation. There are specific circumstances where the appropriate response to a design review is to pause and require specialist input before proceeding.

Those circumstances include: any design that involves a novel cryptographic construction rather than composition of standard primitives; any system that will hold cryptographic material on behalf of users who cannot rotate their own keys; any design where the consequence of a cryptographic failure is irreversible at scale; and any system that must remain secure against an adversary with access to the codebase.

In those cases, the most valuable thing a non-specialist reviewer can do is recognize the boundary of the framework and ask for help rather than proceeding on instinct. Knowing when to escalate is itself a form of cryptographic competence, and it is considerably more accessible than the expertise required to resolve the underlying questions.