本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 步骤 8：验证数据加密
<a name="verify-encryption"></a>

**验证数据是否已加密**

1. 查看加密的数据文件（例如 `sales-output.csv`）。

1. 验证以下列：

   1. 列 **1** — 已加密（例如 `username_fingerprint`）。

      对于 fingerprint 列 (HMAC)，在版本和类型前缀（例如 `01:hmac:`）之后，有 44 个字符的 base64 编码数据。

   1. 列 **2** — 未加密（例如 `purchased`）。

   1. 列 **3** — 已加密（例如 `product_sealed`）。

      对于已加密 (SELECT) 列，cleartext 的长度加上版本和类型前缀（例如 `01:enc:`）后的任何填充，与加密后的 cleartext 的长度成正比。也就是说，长度等于输入的大小加上大约 33% 的编码开销。

您现在已准备好执行以下操作：

1. [将加密的数据上传到 S3](prepare-data-S3.md#upload-to-s3)。

1. [创建 AWS Glue 表](prepare-data-S3.md#create-glue-crawler)。

1. [在 AWS Clean Rooms中创建配置表](create-configured-table.md)。

C3R 加密客户端将创建不包含未加密数据的临时文件（除非这些数据在最终输出中也未加密）。但是，某些加密值可能无法正确填充。即使协作设置 `allowRepeatedFingerprintValue` 为 `false`，指纹列也可能包含重复的值。之所以出现此问题，是因为临时文件是在检查正确的填充长度和重复项删除属性之前写入的。

如果 C3R 加密客户端失败或在加密过程中中断，则它可能会在写入临时文件之后但在检查这些属性和删除临时文件之前停止。因此，这些临时文件可能仍在磁盘上。在这种情况下，这些文件中的内容对明文数据的保护程度将不如输出文件。特别是，这些临时文件可能会向统计分析揭示明文数据，而这些数据不会对最终输出产生影响。用户应删除这些文件（尤其是 SQLite 数据库），以防止这些文件落入未经授权的人手中。