Applied cryptography architecture
Decide which cryptographic mechanisms protect which data against which adversary
A product is choosing encryption, signing or tokenisation mechanisms, or an existing choice is being questioned. The decision is which cryptographic mechanisms protect which data against which adversary. The work starts from what each mechanism protects against, who holds the key, and where plaintext still exists and ends with a cryptographic architecture assessment with mechanism decisions and residual exposure. It is most relevant to security architects and engineering leads. A useful result states what was examined, what remains uncertain and which decision the evidence can support.
Decide which cryptographic mechanisms protect which data against which adversary
- Protected asset
The starting condition this work depends on.
- Key custody
Where the consequence actually arises.
- Residual exposure
The finding and its open dependencies.
Decision
Frame the decision before scoping the work
Questions and the evidence each one needs
- Protected asset
- Inspect data classification and flow descriptions.
- Key custody
- Inspect the current cryptographic inventory and library usage.
- Residual exposure
- Inspect threat statements and compliance obligations.
The decision is which cryptographic mechanisms protect which data against which adversary. This matters to security architects and engineering leads when a product is choosing encryption, signing or tokenisation mechanisms, or an existing choice is being questioned. Name the affected system, the consequence of a wrong decision and the owner who can act. The opening conversation should establish which evidence already exists and which uncertainty is material enough to investigate.
The specific failure hypothesis is that data is encrypted at rest with a key the same service can always read, against an attacker who already has that service. It stays a hypothesis until it is examined in your own case. Existing design records, inventories or operating evidence may already resolve it, so identify the uncovered question before commissioning further work.
Mechanism
Follow the relationship that carries the consequence
Where the boundary is actually crossed
- Protected asset
- The condition the design assumes.
- Key custody
- Where authority or information changes hands.
- Residual exposure
- The effect the owner must answer for.
What this specialty examines
Applied cryptography architecture rests on what each mechanism protects against, who holds the key, and where plaintext still exists. Work from the mechanism as deployed and its actual key custody rather than from the standard it cites, and record where the two differ.
The examination draws on data classification and flow descriptions; the current cryptographic inventory and library usage; and threat statements and compliance obligations. Identify the owner, revision and operating context of each source. Keep an incomplete input visible, with an explanation of what its absence prevents the owner from concluding, rather than quietly treating a gap as a satisfactory result.
The tradeoff to make explicit
The tradeoff here is a stronger separation of key custody against the operational complexity it introduces. Compare the available options against the same intended outcome. If one option removes a control or moves a boundary, describe that difference before treating its lower effort as an improvement. The decision should expose the tradeoff rather than bury it in a single rating.
Preparation
Connect the inputs to the boundary examined
Preparation record for the engagement
Illustrative working format
- Data classification and flow descriptions
- Bounds the context.
- The current cryptographic inventory and library usage
- Supplies the material examined.
- Threat statements and compliance obligations
- Exposes conditions that qualify a result.
Start with data classification and flow descriptions; the current cryptographic inventory and library usage; and threat statements and compliance obligations. Each has a different job: the first establishes context, the second supplies the material to examine, and the third exposes operating conditions that may qualify a conclusion. Sanitised examples can support early work, provided the differences from the real configuration stay explicit.
The scope also needs security architects and engineering leads with the authority to inspect the relevant boundary, and agreement on what evidence would distinguish the failure in which data is encrypted at rest with a key the same service can always read, against an attacker who already has that service from acceptable behaviour. Where stakeholders disagree about intended behaviour, resolve that interpretation before classifying an observed difference as a defect.
Working sequence
Carry the question through to an accountable finding
From scoped material to a decision record
- State the adversary and the asset
Set the conditions assumed.
- Examine the mechanism in place
Apply the scoped check.
- Place the boundary deliberately
Record evidence and the next decision.
State the adversary and the asset
For each protected data class, name the adversary the cryptography is meant to exclude and the point at which protection must hold. Record what is deliberately excluded.
Examine the mechanism in place
Inspect algorithm, mode, parameter and library choices, and follow where plaintext, keys and authentication tags exist at run time. Keep an unreproducible observation in the record with its reason.
Place the boundary deliberately
Decide where encryption, signing or tokenisation sits relative to the trust boundary it is meant to defend, and what remains unprotected. Hand the result over with its open dependencies attached.
Indicative artefact
Make the artefact usable by the person who owns the decision
A cryptographic architecture assessment with mechanism decisions and residual exposure
Illustrative working format
- Adversary and asset statements per data class
- What was examined, and under which assumptions.
- Mechanism, parameter and library findings
- Each observation, linked to evidence.
- Placement decisions and remaining plaintext exposure
- The next decision, and its limits.
The proposed decision artefact is a cryptographic architecture assessment with mechanism decisions and residual exposure. Depending on the agreed scope, the pack may include:
-
Adversary and asset statements per data class. Basis: the definitions, boundaries and assumptions another reviewer would need.
-
Mechanism, parameter and library findings. Observation: the findings and their interpretation, preserving adverse results and disagreement.
-
Placement decisions and remaining plaintext exposure. Decision: what the owner could do next, and what change would justify revisiting it.
Retain the selection rationale beside the result. Without it, a bounded finding is easily mistaken for complete coverage.
Illustrative scenario
Examine the question through a constructed case
A constructed case and its decision paths
Illustrative scenario
- Protected asset
A service encrypts a database column and stores the key in the same service's configuration.
- Key custody
Which adversary does this exclude, given that compromising the service yields both?
- Residual exposure
Move key custody outside the service boundary, or state plainly that the control addresses storage-media loss only.
Consider an illustrative situation: a service encrypts a database column and stores the key in the same service’s configuration. The example is constructed to show how the question is framed. No client engagement, executed test or measured improvement is implied.
The question to examine is which adversary does this exclude, given that compromising the service yields both. A reasonable next action would be to move key custody outside the service boundary, or state plainly that the control addresses storage-media loss only. The decision record should state which configuration was accepted and which limitations came with it.
Scope and next action
Keep the conclusion inside the agreed boundary
Confirm fit before the next commitment
- Protected asset
- Limited to the agreed scope and configuration.
- Data classification and flow descriptions
- The owner confirms access and conditions.
- Residual exposure
- An architecture assessment is not cryptanalysis. Evaluating a primitive's mathematical strength requires separately qualified specialists.
An architecture assessment is not cryptanalysis. Evaluating a primitive’s mathematical strength requires separately qualified specialists. Any engagement depends on an agreed scope, a qualified team and authorised access.
Bring the affected system, the inventory you already have and the obligation that prompted the question. The scope question follows from the situation in which a product is choosing encryption, signing or tokenisation mechanisms, or an existing choice is being questioned. Confirm which missing observation would change the owner’s next action.