Go crypto/cipher.AEAD Seal 如何复用明文缓冲区减少额外分配

使用 cipher.AEAD 加密短消息时，最容易写成 aead.Seal(nil, nonce, plaintext, aad)。这段代码安全边界清楚，但每次都会把密文追加到一个新的空切片上。如果明文后续不再使用，且调用方已经为认证标签预留了容量，可以把 plaintext[:0] 作为 dst，让 Seal 尽量复用明文的底层存储。

关键不是盲目追求“原地加密”，而是同时满足三个条件：dst 的剩余容量足够容纳密文、dst 与明文的重叠方式符合 AEAD 契约、additionalData 不与它们共享冲突的存储。

先看懂 Seal 的 dst 语义：明文可以原地变成密文

Seal 会把认证后的密文追加到 dst，返回更新后的切片。官方接口明确给出了复用明文存储的写法：把 plaintext[:0] 作为目标切片。这里的 [:0] 只把长度归零，仍然保留原切片的容量和底层数组。

// 这段示例只展示缓冲区关系；真实项目应从安全位置加载密钥。
block, err := aes.NewCipher(key)
if err != nil {
    return nil, fmt.Errorf("创建 AES: %w", err)
}

// NewGCM 使用标准 nonce 长度；nonce 必须为同一密钥下的每条消息保持唯一。
aead, err := cipher.NewGCM(block)
if err != nil {
    return nil, fmt.Errorf("创建 GCM: %w", err)
}

// 明文不再需要时，先把长度归零作为 dst，保留底层数组供 Seal 追加。
ciphertext := aead.Seal(plaintext[:0], nonce, plaintext, additionalData)
return ciphertext, nil

这段写法的语义是“允许复用”，不是“保证零分配”。如果 plaintext 的剩余容量放不下完整密文，Seal 仍可能扩容并分配新的底层数组；如果明文后面还要继续读取，也不能把它当作不可变副本继续使用。

容量够不够，决定了是否真的复用底层数组

AEAD 密文长度通常等于明文长度再加上 aead.Overhead()。因此只给明文长度的容量，往往无法装下认证标签。更稳妥的做法是在准备明文缓冲区时就把容量设为“明文长度加最大开销”，然后再把它交给 Seal。

// 先准备一块带尾部空间的明文缓冲区，尾部空间用于认证标签。
plain := make([]byte, len(input), len(input)+aead.Overhead())
copy(plain, input)

// 复用 plain 的底层数组；Seal 返回的切片长度会变成明文长度加认证开销。
ciphertext := aead.Seal(plain[:0], nonce, plain, aad)

// 现在 plain 不应再被当作独立明文读取，后续只使用 ciphertext。
return ciphertext, nil

如果输入本来就来自一个拥有额外容量的接收缓冲区，可以直接沿用它；如果输入是外部调用方持有的只读语义数据，则应先复制到调用方独占的工作缓冲区。这个复制是否值得，取决于消息大小、调用频率和生命周期，而不是由 Seal 自动替你决定。

别名边界不能省：additionalData 与明文要分开

plaintext[:0] 是文档明确允许的复用入口，但不代表所有切片重叠都安全。dst 的剩余容量不能与 plaintext 形成不精确重叠，dst 也不能与 additionalData 重叠。最省心的工程规则是：工作缓冲区只归当前加密调用独占，附加认证数据使用独立且稳定的切片。

// aad 只参与认证，不把它放进 plaintext 的底层数组范围内。
aad := []byte("tenant=demo;version=1")

// plaintext 的所有权交给本次 Seal；返回后不要继续修改或读取它的旧内容。
ciphertext := aead.Seal(plaintext[:0], nonce, plaintext, aad)

// 如果无法证明切片关系，就使用独立输出，优先保证边界清晰。
safeCiphertext := aead.Seal(nil, nonce, input, aad)

另外，nonce 的唯一性和缓冲区复用是两件事。复用底层数组不会替代 nonce 管理，也不会自动让重复 nonce 变得安全。性能优化只应改变存储路径，不应改变协议要求。

生产代码的加固清单

• 先确认明文在 Seal 返回后不再被业务逻辑读取；需要保留时使用独立输出。
• 用 aead.Overhead() 计算容量，不要写死某个算法的认证标签长度。
• 检查 dst、plaintext、additionalData 的底层数组关系，无法证明时宁可分配新输出。
• 继续独立处理 nonce 生成、密钥生命周期和 Seal 返回值；复用缓冲区不等于完成了加密方案设计。

可以把结论记成一句话：plaintext[:0] 是复用入口，len+Overhead 是容量前提，独占缓冲区是边界保障。三者同时成立时，才值得把这项优化放进热点路径。

常见问题

为什么用了 plaintext[:0] 仍然看到扩容？

通常是剩余容量不足以放下完整密文，尤其是没有为 Overhead 预留空间。也可能是调用方传入的切片本身没有可用尾部容量。用 cap(plaintext)-len(plaintext) 先判断空间，或者在准备工作缓冲区时一次性设置容量。

复用明文底层数组会不会改变安全性？

复用本身不是安全性保证，也不是安全性破坏；它只是改变输出存储位置。必须继续遵守 nonce 唯一、附加数据独立和输入输出别名规则，并在返回后停止使用被覆盖的明文切片。