SSE-C 副本完整性

本文记录由 #122、#123、#124、#126 和 #134 共同构成的 SSE-C 副本完整性契约（随 Server 20260916 发布），与此前在 Server 20260903 中发布的零字节/属性读取认证及目标密钥 checksum 响应修复衔接。

密文与信任

普通 SSE-C 请求提供客户密钥，操作明文。经过授权的副本传输可以携带原始密文和保留原对象所需的密封对象密钥元数据。目标必须原样存储这些字节，再加密一次会产生不可读的双重加密对象。内部标记本身不是授权：仍需精确复制标记和要求的复制权限。

该路径不会泄露客户密钥，也不会允许普通无密钥读取。普通 GET/HEAD 与 GetObjectAttributes 保留各自密钥/权限检查。联邦原始 SSE-C 副本 COPY 明确不支持。

分段大小与校验和

加密分段大小与逻辑明文分段大小不同。副本多段记录必须保留每段实际逻辑大小，使覆盖后的 partNumber 读取、范围读取和 GetObjectAttributes 与源一致。Checksum 必须保留正确加密上下文和逻辑含义；对象已用另一把目标密钥提交后，不能仍用源密钥解密响应 checksum。

普通 SSE-C 密钥轮换只要显式请求 checksum 算法，就走完整重写，即使算法与原值相同。多段源成为单段目标，ETag 可能变化，复制重传对象字节。不带该请求且满足元数据原位更新条件时，保留原 checksum 状态，包括缺失状态。详见操作步骤。

重传与 Object Lock

目标无密钥 HEAD 可能把已存在的 SSE-C 对象报告为不可访问，而不是不存在。发送方须区分它与 NoSuchKey，不能假设普通元数据 COPY 能修好副本。已存在 SSE-C 副本走对象重传。旧副本状态无法解码时，可通过修复后的重传路径替换，同时保留目标更新的 Object Lock 状态，并正确排序删除时间戳。

升级 Server 不会自动修复已损坏的历史副本。审计存量副本时，应使用批准的密钥访问流程重新读取精确源/副本版本，比较逻辑字节和分段边界，并另行检查保留期及 legal hold，不能仅凭元数据 HEAD 成功推断完整性。

压缩与历史对象

SILO 排除所有新 SSE-C 写入的压缩，包括普通 PUT、多段初始化、COPY 和 Snowball。SSE-S3/SSE-KMS 仍服从加密压缩选项。这避免生成传送密文却缺少所需压缩元数据的副本格式。

历史压缩 SSE-C 对象不会自动重写。应保留密钥和精确版本身份，清点影响范围并演练受支持的重写/恢复路径。

验证边界

压缩判定、replication-trust-ssec-replica_test.go、erasure-multipart-ssec-replica_test.go、replication-ssec-retransmit_test.go 和 compression-ssec_test.go 固定了相关源码及回归契约，涵盖错误密钥/未授权对照、多段字节比较和重传场景。

相关内容见 Object Lock 排序、多池一致性及副本恢复。依赖组合行为前须升级所有参与 Server。