Cryptographic Erase Mathematics: Entropy and Surviving Keys

Short answer

A large key space can make blind guessing difficult under explicit assumptions. It cannot prove cryptographic erasure when a usable key copy survives, plaintext exists elsewhere or the implementation exposes another recovery path. Calculate the guessing case separately from those operational questions.

This article derives a simple classical guessing model and a proposed two-route illustration for key survival. The mathematics is conditional, not a sanitization standard, a new physical law or a probability estimate for a real device. No number below establishes that an actual key was generated well or removed successfully.

Who this is for

This guide is for engineers and sanitization reviewers who encounter claims such as “the key has 128 bits, therefore deletion is proven.” It explains what a key-space calculation can support and what evidence it still needs. It does not prescribe an erase command or assess a named product.

FIPS 197, updated May 2023, specifies AES key lengths of 128, 192 and 256 bits. Key length describes the algorithm's key representation; it is not a measurement of how unpredictable a particular generated secret is. NIST SP 800-90B, January 2018, defines min-entropy for probability distributions. NIST SP 800-88 Rev. 2, September 2025, treats cryptographic erase as dependent on cryptographic strength, key management and applicability conditions, not a key-length label alone.

When to use this

Use the model to inspect an argument, compare hypothetical assumptions or explain why key-copy control remains essential. It is useful when a report contains a large exponent but omits its threat model or evidence about the key lifecycle.

Keep the operational result outside the equation: an actual acceptance decision needs supported encryption coverage, applicable key sanitization and treatment of retained copies. A spreadsheet cannot observe those facts merely by assigning variables to them.

When not to use this

Do not use the formulas as an attacker benchmark, a universal time-to-crack estimate or proof that a storage device is purged. Do not assume uniform key generation from a hexadecimal string's length. Do not feed real keys, passwords or customer ciphertext into a demonstration.

The model excludes quantum search, cryptanalytic shortcuts, side channels and implementation compromise. It also excludes recovery of plaintext that was never protected by the key being discussed. Those exclusions are material, not small rounding errors.

Workflow

1. Define the guessing experiment

Assume one secret key is chosen uniformly from N possible values. The attacker has no information that favors any candidate, can recognize a correct guess, and tests g distinct candidates without repeating guesses. The attack considered here is classical exhaustive guessing only.

Symbol	Meaning	Unit or range
b	Uniform key-space width	bits; nonnegative integer
N	Number of equally likely keys	count; N = 2^b
g	Distinct tested candidates	count; integer from 0 through N
p	Success probability in this experiment	dimensionless, 0 through 1
h	Min-entropy lower bound under the stated information	bits
q	Assumed probability of obtaining a usable surviving copy in the later toy model	dimensionless, 0 through 1

Uniformity and absence of useful side information are assumptions about the experiment. They are not facts established by reading a drive's feature sheet.

2. Derive the uniform result

Each candidate has probability 1/N of being the secret. For g different guesses, the successful-key events are disjoint. Summing their probabilities gives:

N = 2^b
p = g / N = g * 2^(-b), for 0 <= g <= N

For a finite toy space of eight equally likely keys, testing three distinct keys succeeds with probability 3/8. Testing all eight succeeds with probability one. These boundaries help expose formulas that incorrectly predict a probability above one.

The formula concerns a fixed budget of distinct guesses. Repeating guesses wastes budget. If information favors some keys, the uniform formula no longer describes the actual distribution seen by the attacker.

3. Work a numerical example

Take a hypothetical uniform 128-bit key and a budget of one trillion distinct guesses. The space contains 2^128, approximately 3.4028 × 10^38, possibilities. The model gives:

b = 128 bits
g = 10^12 guesses
p = 10^12 / 2^128 ≈ 2.9387 × 10^(-27)

This is a dimensionless probability conditional on the specified experiment. The guess count is fictional; no hardware speed, time horizon or real attack throughput is asserted. A tiny result does not measure a drive's erase operation, key-copy handling or encryption coverage.

A different budget changes p proportionally until the entire finite space has been tested. A different key-generation distribution changes the model itself, not merely the last decimal place.

4. Replace length with an explicit uncertainty bound

For a discrete key distribution, let p_max be the largest probability of any individual key under the stated attacker information. Min-entropy is:

H_inf = -log2(p_max)

If H_inf is at least h bits, no individual candidate has probability greater than 2^(-h). Any set of g distinct guesses therefore has total probability at most the sum of g such bounds:

p <= min(1, g * 2^(-h))

This is an upper bound, not an equality for every nonuniform distribution. It assumes h actually bounds the relevant key distribution after accounting for the information available to the attacker. A source's entropy assessment is not automatically the entropy of every derived key under every disclosure scenario.

For a fictional h = 80-bit lower bound and g = 10^12, the expression is approximately 8.2718 × 10^(-13). These inputs do not describe a measured product. They show why storing a secret in a 128-bit field does not justify substituting 128 for an unsupported uncertainty bound.

Do not estimate h by inspecting one key or counting the characters in a password. Justifying a bound requires a key-generation and information model; this article does not perform an entropy-source assessment.

5. Put a surviving key route outside blind guessing

Define event C as the attacker obtaining a usable surviving key copy through a recovery route. Let q = P(C). For this deliberately simplified illustration, assume success is certain on C and, conditional on not C, only the uniform guessing experiment remains. The law of total probability then gives:

P(success) = q * 1 + (1 - q) * (g / N)

No independence assumption between C and the rest of the system is being inferred: the uniform guessing behavior on not C is explicitly an additional conditional assumption. The formula covers only these two routes. If other routes exist, it is not a complete system-risk model.

Choose q = 0.001 purely as a toy input, with the preceding 128-bit space and guess budget. The total is approximately 0.001, dominated by the assumed key-copy route rather than blind guessing. This does not assert a 0.1-percent copy-survival rate in real systems. It illustrates that a small guessing term cannot cancel an unaddressed recovery route.

An operational reviewer often cannot justify any numerical q at all. In that case, record “unresolved key-copy path” rather than presenting a fabricated probability with many digits. Documentation about escrow, wrapping keys, backups and the exact sanitization operation is more useful than choosing a convenient q.

6. Check the arithmetic without interacting with hardware

This Python 3 calculation uses exact fractions for the model and converts only for displayed output. It generates no key and performs no storage operation:

from fractions import Fraction

b, g = 128, 10**12
N = 2**b
p = Fraction(g, N)
bound80 = min(Fraction(1), Fraction(g, 2**80))
q = Fraction(1, 1000)
toy_total = q + (1 - q) * p

assert Fraction(3, 8) == Fraction(3, 2**3)
assert 0 <= p <= 1
assert q <= toy_total <= 1
print(f"{float(p):.4e}")
print(f"{float(bound80):.4e}")
print(f"{float(toy_total):.3f}")

Expected output is 2.9387e-27, 8.2718e-13 and 0.001. Reproducing it checks the published arithmetic. It does not validate the uniformity, entropy bound, copy probability or implementation assumptions.

7. Return to the sanitization decision

For an actual device, identify the target encrypted data, relevant keys and supported key-sanitization operation. Determine whether earlier plaintext, usable key copies or other recovery paths are within scope. Treat an unknown prerequisite as unknown.

Keep three evidence statements separate: the cryptographic design has a stated strength, the chosen operation completed, and the result was accepted for this asset's target scope. None follows solely from the numerical example above. If the necessary conditions are not supported, select another authorized method or retain the asset as an exception.

Verification checklist

• Key-space and attacker assumptions explicit.
• Counts, probabilities and bits distinguished.
• Distinct guesses stay within the finite space.
• Min-entropy bound justified rather than inferred from length.
• Key-copy and plaintext routes assessed separately.
• Toy probabilities not presented as measured rates.
• Arithmetic separated from hardware and implementation evidence.
• Final acceptance covers the actual asset and method.

Verification note: mathematical scope

The pure Python arithmetic was checked independently; no key generation, cryptographic erase, hardware test or recovery experiment was performed for this article. The formulas are elementary probability derivations applied to a proposed explanatory model. They are not a certificate of erasure or a new scientific law.

The key-copy example intentionally exposes a limitation: if C is certain, success is one regardless of b in this toy model. If C is absent and the uniform assumptions hold, the result reduces to g/N. These are model boundary checks, not observations of a device.

Resale and evidence checklist

Attach the actual supported method and completion evidence to the asset's record. Retain unresolved key-lifecycle questions for the acceptance reviewer. Do not label hardware sanitized solely because its encryption algorithm supports a long key.

What not to publish

Publish no real keys, customer ciphertext, recovery credentials or invented probability of a vendor failure. Avoid claims that AES key length, entropy arithmetic or successful code execution proves irreversible data removal. No forthcoming product capability or certification is established here.

Common mistakes

Common errors are confusing key length with entropy, turning an upper bound into an equality, forgetting that copied keys avoid guessing, and presenting a fictional guess budget as a measured attack rate. Another is applying a one-key model to a multi-key system without defining what constitutes success.

CliDeck workflow fit

Use the model to make review assumptions visible beside the operational evidence. A repeatable record can keep unsupported prerequisites from disappearing behind a large exponent. It cannot supply missing key-management or implementation facts.

FAQ

Does doubling key length prove better erasure?

It changes a guessing model under its assumptions. It does not demonstrate that the relevant key copies were sanitized.

Can I use the toy q as a real failure rate?

No. It is an explanatory input with no empirical basis here.

Does a min-entropy bound prove cryptographic erasure?

No. It bounds a specified guessing problem; it does not account for every way to obtain plaintext or a surviving key.

Related guides

Review key-copy and recovery-path scope, NIST program acceptance, and the evidence coverage model. Keep the certificate record honest about what was actually verified.