The direct answer
Before an encryption attempt, require supported evidence that its nonce belongs to a fresh, exclusively owned range under the actual key. Keep used, uncertain and abandoned positions unavailable under the recovery policy. A crash, missing ciphertext or older snapshot cannot make a same-key nonce fresh again.
Separate a fresh attempt from a reusable nonce
A trusted writer encrypts a small AI-generated maintenance note. It then crashes before recording whether ciphertext was produced. Retrying the business job and reusing its cryptographic inputs are different decisions. The writer cannot make the earlier nonce fresh by calling the operation a retry.
This original worksheet selects one already admitted IETF ChaCha20-Poly1305 AEAD implementation and one trusted writer under a fixed key epoch. It reviews allocation metadata only. The existing associated-data worksheet keeps its separate AESGCM profile; its trusted-context rule supplies no nonce allocator. Neither page implements a cryptosystem.
K-A denotes the actual key association, W-A an admitted writer namespace, and A-A the ordinary note. These are fictional references, never key material or encoded nonce bytes. An arbitrary label saying “new key” is insufficient evidence that K-A changed.
Freeze the documented contract before designing recovery
RFC 5116, a January 2008 Standards Track document, requires distinct nonces for separate encryption invocations under a fixed key in its nonempty-nonce case. Its formation guidance combines fixed and increasing counter fields, permits skipped counters, and requires distinct fixed fields for devices sharing a key. For keys surviving reboot, it discusses persistent checkpoints: wait for storage confirmation of a succeeding value, optionally recording several values ahead.
RFC 8439, a June 2018 Informational document, specifies the selected AEAD with a 256-bit key and 96-bit nonce, different for each invocation under that key. It describes a sender-distinct first 32 bits with a remaining 64-bit counter. Its security discussion explains that nonce repetition repeats the keystream and one-time Poly1305 key, exposing the XOR of plaintexts.
Those historical documents support this narrow lifecycle review. They establish no current deployment recommendation, installed implementation, approved storage design or safe operating volume. The proposed external allocation counter is separate from the cipher’s internal block processing; this article supplies no encryption routine or message-size implementation.
Use an allocation ledger with an explicit exclusion boundary
Invent a paper ledger in which values below 40 are unavailable for new allocation. The writer intends to reserve counters 40 through 47. Before any associated attempt becomes eligible, the ledger needs independently supported confirmation that its next-unallocated boundary is 48. The example uses eight symbolic positions for readability, not a recommended reservation size.
| Review point | Required disposition |
|---|---|
| Key and writer association | Bind K-A/W-A to the actual approved key, namespace and encoding profile. |
| Range proposal 40–47 | Still ineligible while durable exclusion of that range is unconfirmed. |
| Supported confirmation of boundary 48 | Only the designated owner may use this reserved range under the admitted plan. |
| Recovered owner after interruption | Discard the prior range and obtain a separately supported fresh allocation at or beyond the confirmed boundary. |
The recovered process does not simply encrypt with 48 on reading that number. That value is the next allocation boundary, not evidence of an already reserved new range. Reservation must itself be supported before use. A response from a storage helper, familiar filename or matching process identifier cannot substitute for the required persistence and ownership evidence.
Treat uncertain use and restored state conservatively
Suppose the writer completed the reservation and attempted counter 40, but the encryption result is unavailable. Our application policy permanently excludes that position from future attempts. It makes no claim about whether ciphertext exists. Deleting an output record or observing an empty destination cannot establish that the invocation never happened.
After a crash, this policy also abandons the remaining positions in the old range. That deliberate loss of capacity simplifies the recovery decision; it is an original stricter policy, not a claim that the RFC mandates this exact range size or ledger schema. A financial reservation may later release unused funds, whereas this policy never recycles its abandoned cryptographic positions.
A restored snapshot reporting boundary 40 cannot supersede later evidence of 48. If all authoritative allocation evidence was rolled back or cloned, uniqueness remains unknown. Hold the same-key workflow; do not select a convenient counter, switch algorithms or invent fresh key material as an automatic repair. Independent recovery and key-management procedures remain outside this worksheet.
Review eight inert eligibility cards
| Invented observation | Proposed decision |
|---|---|
| 1. Actual prerequisites, supported reservation, fresh position and current A-A rights all established | Eligible only for the fixed ordinary note attempt; no encryption or delivery is claimed. |
| 2. Range checkpoint is unconfirmed | Do not admit any attempt from that range. |
| 3. An attempt’s result is unavailable | Keep its position excluded regardless of uncertain ciphertext. |
| 4. Writer restarts with unused positions in its previous range | Discard that range under this policy; require a new supported reservation. |
| 5. Older snapshot or cloned writer could overlap allocation | Hold until independent lifecycle evidence resolves overlap. |
| 6. Another writer shares the same namespace or allocated range | Reject the ownership contract; one healthy writer proves no global exclusion. |
| 7. Counter domain is exhausted or only the key label changed | Stop allocation; no wraparound or inferred new-key history. |
| 8. Allocation passes but object context, content or current rights fail | Withhold the operation or release independently. |
Keep the conditional positive visibly unimplemented
Actual key custody and epoch identity, complete writer inventory, collision-free namespace assignment, injective encoding, supported algorithm/backend and input bounds, durable monotonic allocation, exclusive ownership through invocation, backup/restore coordination and current artifact authority are independent prerequisites. They are currently unknown and unimplemented here, so the positive authorizes no real operation.
No key, nonce, counter buffer, ciphertext, tag, encoding, checkpoint, storage transaction, restoration fixture, crypto import, API or model call was created or run. No physical durability, memory wiping, replay detection or secure deletion is established. Boundary is prelaunch; its planned request checks and existing synthetic policy evidence do not provide this allocator, encryption service or recovery implementation.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.