In Go's cipher.AEAD, which overlap between Seal's dst and plaintext is allowed?

## The rule `crypto/cipher` documents one and only one legal aliasing between a `Seal` call's destination and its plaintext: > To reuse the plaintext's storage for the encrypted output, use `plaintext[:0]` as `dst`. Otherwise, the remaining capacity of `dst` must not overlap the plaintext. The distinction is between **exact** and **inexact** overlap. Exact means the region `Seal` will write begins at the very same address as the plaintext it will read — the two slices march forward together, and GCM's counter mode reads each byte before it writes over it, so this is safe and is the intended in-place idiom. Inexact means the write region and the read region share an array but start at different offsets. There, `Seal` would clobber plaintext bytes it has not consumed yet, silently producing a record that decrypts to garbage. Go does not leave that to chance. The `crypto/cipher` implementations check for inexact overlap and **panic** — `crypto/cipher: invalid buffer overlap` — rather than emit a corrupt ciphertext. A panic in a batch job is recoverable; an archive full of records that no longer decrypt is not. ## How the bug is actually written The shape that trips people up comes from optimising, not from carelessness. A job encrypting archive chunks on their way to object storage reuses one large buffer per chunk to keep allocations flat. It reads the chunk into the buffer at an offset, leaving room at the front for the 12-byte nonce, and then tries to seal from the front so the whole record is contiguous and can be written in one call: ```go buf := make([]byte, 12+chunkSize+gcm.Overhead()) n, _ := io.ReadFull(src, buf[12:12+chunkSize]) plain := buf[12 : 12+n] record := gcm.Seal(buf[:0], nonce, plain, nil) // panics ``` `buf[:0]` has capacity for the whole record, so `Seal` will not allocate; it will write starting at `buf[0]`. The plaintext lives at `buf[12:]`. The write region and the read region overlap, at different offsets, and the call panics. The reason it feels correct is that the same trick with the `append` builtin *is* fine. `append` copies bytes forward one at a time and callers rarely notice; a cipher reads and writes the same window under a keystream and cannot. Aliasing rules that hold for slices in general do not carry over to `crypto/cipher`. ## The three fixes 1. **Let `Seal` allocate.** `gcm.Seal(nil, nonce, plain, nil)` is always correct and is the right default until a profile says otherwise. One allocation per chunk on a job that is doing AES on megabytes is very rarely the bottleneck. 2. **Use the exact in-place form.** `gcm.Seal(plain[:0], nonce, plain, nil)` encrypts into the plaintext's own storage — no allocation, no overlap violation. The record's nonce prefix then has to be dealt with separately: write the nonce to the sink first and the ciphertext second, or keep a small separate 12-byte header slice. 3. **Separate the arrays.** Read the plaintext into one buffer and seal into another. Two reused buffers still means zero allocations per chunk and no aliasing question at all. ## Open has the same rule, plus one more `Open`'s documented in-place form is `ciphertext[:0]` as `dst`, and any other overlap panics for the same reason. It carries an extra warning worth knowing: **even when `Open` returns an error, the contents of `dst` up to its capacity may have been overwritten.** So a decrypt path that reuses a buffer cannot assume the buffer still holds anything meaningful after a failed verification, and must not hand a partially written destination to anything downstream. ## Proving it, and proving the optimisation was worth it This defect has an unusually clean test. A round-trip unit test that seals one chunk and opens it again catches the panic immediately — but only if the test exercises the **real** buffer strategy. A test that calls `make` fresh per case has no aliasing and passes happily while production panics. Write the test against the same reused buffer the job uses, across several chunk sizes including one that fills the buffer exactly and one shorter than it, so the offsets vary. And since the whole reason to alias buffers is speed, the second half of the work is measuring it: a benchmark run with `-benchmem` tells you whether the in-place form actually removed allocations per operation, or whether you have taken on an aliasing hazard for a change that AES throughput swallows entirely. "Make it faster without changing behaviour" means the benchmark, not the intuition, decides whether the risky form stays.