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

C3R 加密客户端指南

C3R 加密客户端是一种工具，它使组织能够将敏感数据整合在一起，从数据分析中获得新的洞察。该工具以加密方式限制了任何一方和在此过程中可以学到 AWS 的内容。尽管这一点至关重要，但以加密方式保护数据的过程可能会在计算和存储资源方面增加大量开销。因此，了解使用每种设置的利弊得失以及如何在保持所需的加密保障的同时优化设置非常重要。本主题重点介绍 C3R 加密客户端和架构中不同设置对性能的影响。

所有 C3R 加密客户端加密设置都提供不同的加密保障。默认情况下，协作级别的设置是最安全的。在创建协作时启用其他功能会削弱隐私保障，从而允许对加密文字进行频率分析等活动。有关如何使用这些设置及其影响的更多信息，请参阅Clean Rooms 加密计算。

对列类型的性能影响

C3R 使用三种列类型：cleartext、fingerprint 和 sealed。每种列类型都提供不同的加密保障，并且具有不同的预期用途。在以下各节中，将讨论列类型的性能影响以及每种设置对性能的影响。

Cleartext 列

Cleartext 列不会改变其原始格式，也不会以任何方式进行加密处理。此列类型无法配置，也不会影响存储或计算性能。

Fingerprint 列

Fingerprint 列旨在用于联接多个表中的数据。为此，生成的加密文字大小必须始终相同。但是，这些列受协作级别设置的影响。Fingerprint 列可能会对输出文件大小产生不同程度的影响，具体取决于输入中包含的 cleartext。

fingerprint 列的基本开销

fingerprint 列有基本开销。这种开销是恒定的，与 cleartext 字节的大小无关。

fingerprint 列中的数据通过 HMAC 散列消息认证码函数进行加密处理，该函数将数据转换为 32 字节的消息认证码 (MAC)。然后通过 base64 编码器对这些数据进行处理，使字节大小增加约 33%。它前面有一个 8 字节的 C3R 标识，用于指定数据所属的列类型以及生成数据的客户端版本。最终结果为 52 字节。然后将此结果乘以行数得出总基本开销（如果 preserveNulls 设置为 true，则使用非 null 值总数）。

下图显示了如何操作 BASE_OVERHEAD = C3R_DESIGNATION + (MAC * 1.33)

fingerprint 列中的输出加密文字将始终为 52 字节。如果输入 cleartext 数据的平均值超过 52 字节（例如，完整的街道地址），则存储空间可能会显著减少。如果输入 cleartext 数据的平均值小于 52 字节（例如，客户年龄），则存储空间可能会显著增加。

fingerprint 列的协作设置

preserveNulls 设置

当协作级别设置 preserveNulls 为 false（默认值）时，每个 null 值都将替换为一个唯一的随机 32 字节，并被当作非 null 处理。结果是，现在每个 null 值都是 52 字节。与此设置为 true 且 null 值作为 null 传递时相比，对于包含非常稀疏的数据的表，这可能会增加大量存储需求。

如果您不需要此设置的隐私保障，并且希望在数据集中保留 null 值，请在创建协作时启用 preserveNulls 设置。创建协作后将无法更改 preserveNulls 设置。

fingerprint 列的示例数据

以下是带有要重现设置的 fingerprint 列的输入和输出数据的示例集。其他协作级别的设置（例如 allowCleartext 和 allowDuplicates）不会影响结果，如果尝试在本地重现，则可以设置为 true 或 false。

共享密钥示例：wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

协作 ID 示例：a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

allowJoinsOnColumnsWithDifferentNames：True 此设置不会影响性能或存储要求。但是，在重现下表中显示的值时，此设置使列名的选择变得无关紧要。

fingerprint 列疑难解答

为什么我的 fingerprint 列中的加密文字比进入它的 cleartext 大几倍？

fingerprint 列中的加密文字的长度始终为 52 字节。如果您的输入数据很小（例如，客户的年龄），则其大小将显著增加。如果将 preserveNulls 设置设置为 false，也可能发生这种情况。

为什么我的 fingerprint 列中的加密文字比进入它的 cleartext 小几倍？

fingerprint 列中的加密文字的长度始终为 52 字节。如果您的输入数据很大（例如，客户的完整街道地址），则其大小将显著减小。

我怎么知道我是否需要 preserveNulls 提供的加密保障？

遗憾的是，答案是“看情况”。至少，应查看 加密计算参数 了解 preserveNulls 设置如何保护您的数据。但是，我们建议您参考组织的数据处理要求以及适用于相应协作的任何合同。

为什么我必须承担 base64 的开销？

为了与 CSV 等表格文件格式兼容，必须进行 base64 编码。尽管某些文件格式（例如 Parquet）可能支持数据的二进制表示，但重要的是，协作中的所有参与者都必须以相同的方式表示数据，以确保查询结果正确。

Sealed 列

Sealed 列用于在协作成员之间传输数据。这些列中的加密文字是不确定的，并且会根据列的配置方式对性能和存储产生重大影响。这些列可以单独配置，通常对 C3R 加密客户端的性能和由此产生的输出文件大小影响最大。

sealed 列的基本开销

sealed 列有基本开销。此开销是恒定的，是 cleartext 和填充（如有）字节大小之外的开销。

在进行任何加密之前，在 sealed 列中的数据前面加上一个 1 字节的字符，表示所包含的数据类型。如果选择了填充，则会对数据进行填充并追加 2 个字节，说明填充大小。添加这些字节后，使用 AES-GCM 对数据进行加密处理，并以 IV（12 字节）、nonce（32 字节）和 Auth Tag（16 字节）进行存储。然后通过 base64 编码器对这些数据进行处理，使字节大小增加约 33%。数据前面有一个 7 字节的 C3R 标识，用于指定数据属于哪种类型的列以及用于生成数据的客户端版本。结果是 91 字节的最终基本开销。然后将此结果乘以行数得出总基本开销（如果 preserveNulls 设置为 true，则使用非 null 值总数）。

下图显示了如何操作 BASE_OVERHEAD = C3R_DESIGNATION + ((NONCE + IV + DATA_TYPE + PAD_SIZE + AUTH_TAG) * 1.33)

sealed 列的协作设置

preserveNulls 设置

当协作级别设置 preserveNulls 为 false（默认值）时，每个 null 值都将是唯一的随机 32 字节，并被当作非 null 处理。结果是，现在每个 null 值都是 91 字节（如果填充，则更多）。与此设置为 true 且 null 值作为 null 传递时相比，对于包含非常稀疏的数据的表，这可能会增加大量存储需求。

如果您不需要此设置的隐私保障，并且希望在数据集中保留 null 值，请在创建协作时启用 preserveNulls 设置。创建协作后将无法更改 preserveNulls 设置。

架构设置 sealed 列：填充类型

none 的填充类型

选择 none 的填充类型不会向 cleartext 增加任何填充，也不会在前面描述的基本开销之外增加额外的开销。没有填充会产生最节省空间的输出大小。但是，它不提供与 fixed 和 max 填充类型相同的隐私保障。这是因为底层 cleartext 的大小可以从加密文字的大小中分辨出来。

fixed 的填充类型

选择 fixed 的填充类型是一种隐私保护措施，用于隐藏列中包含的数据的长度。这是通过在加密之前将所有 pad_length 填充到提供的 cleartext 来完成的。任何超过该大小的数据都会导致 C3R 加密客户端失败。

假设填充是在加密之前添加到 cleartext 的，因此 AES-GCM 具有 cleartext 到加密文字字节的 1:1 映射。base64 编码将增加 33%。填充的额外存储开销可以通过从 pad_length 的值中减去 cleartext 的平均长度，然后乘以 1.33 来计算。结果就是每条记录的平均填充开销。然后将此结果乘以行数得出总填充开销（如果 preserveNulls 设置为 true，则使用非 null 值总数）。

PADDING_OVERHEAD = (PAD_LENGTH - AVG_CLEARTEXT_LENGTH) * 1.33 * ROW_COUNT

我们建议您选择包含列中最大值的最小 pad_length。例如，如果最大值为 50 字节，则 pad_length 为 50 就足够了。大于该值的值只会增加额外的存储开销。

固定填充不会增加任何显著的计算开销。

max 的填充类型

选择 max 的填充类型是一种隐私保护措施，用于隐藏列中包含的数据的长度。这是通过将所有 cleartext 填充到列中的最大值再加上加密之前的额外 pad_length 来完成的。通常，max 填充提供的保障与单个数据集的 fixed 填充相同，同时允许不知道列中的最大 cleartext 值。但是，max 填充可能无法提供与跨更新的 fixed 填充相同的隐私保障，因为各个数据集中的最大值可能有所不同。

我们建议您在使用 max 填充时，额外选择 0 的 pad_length。此长度将所有值填充到与列中最大值的大小相同。大于该值的值只会增加额外的存储开销。

如果已知给定列的最大 cleartext 值，我们建议您改用 fixed 填充类型。使用 fixed 填充可在更新的数据集之间实现一致性。使用 max 填充会使每个数据子集填充到该子集中的最大值。

sealed 列的示例数据

以下是带有要重现设置的 sealed 列的输入和输出数据的示例集。其他协作级别的设置（例如 allowCleartext、allowJoinsOnColumnsWithDifferentNames 和 allowDuplicates）不会影响结果，如果尝试在本地重现，则可以设置为 true 或 false。尽管这些是要重现的基本设置，但 sealed 列是不确定的，值每次都会更改。目的是显示输入字节与输出字节的对比。示例 pad_length 值是故意选择的。它们表明，使用推荐的最低 pad_length 设置或需要额外的填充时， fixed 填充产生的值与 max 填充相同。

共享密钥示例：wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

协作 ID 示例：a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

none 的填充类型

fixed 的填充类型（示例 1）

在此示例中，pad_length 为 62，最大输入为 62 字节。

fixed 的填充类型（示例 2）

在此示例中，pad_length 为 162，最大输入为 62 字节。

max 的填充类型（示例 1）

在此示例中，pad_length 为 0，最大输入为 62 字节。

max 的填充类型（示例 2）

在此示例中，pad_length 为 100，最大输入为 62 字节。

sealed 列疑难解答

为什么我的 sealed 列中的加密文字比进入它的 cleartext 大几倍？

这取决于多个因素。首先，Cleartext 列中的加密文字的长度始终至少为 91 字节。如果您的输入数据很小（例如，客户的年龄），则其大小将显著增加。其次，如果 preserveNulls 设置为 false，并且您的输入数据包含很多 null 值，则每个 null 值都将变成 91 字节的加密文字。最后，如果您使用填充，则根据定义，在加密 cleartext 数据之前会将字节添加到该数据中。

我的 sealed 列中的大部分数据都非常小，我需要使用填充。我可以删除大值并单独处理它们以节省空间吗？

我们不建议删除大值并单独处理。这样做会改变 C3R 加密客户端提供的隐私保证。作为威胁模型，假设观察者可以看到两个加密的数据集。如果观察者发现一个数据子集的列填充明显大于或小于另一个子集，则他们可以推断每个子集中数据的大小。例如，假设 fullName 列在一个文件中填充到总共 40 字节，而在另一个文件中填充到 800 字节。观察者可能会认为，其中一个数据集包含了世界上最长的名字（747 字节）。

使用 max 填充类型时，我需要提供额外的填充吗？

不需要。使用 max 填充时，我们建议将 pad_length（也称为列中最大值之外的额外填充）设置为 0。

我能否在使用 fixed 填充时选择大的 pad_length 来避免担心最大的值是否合适？

能，但是大的填充长度效率低下，并且占用的存储空间超出了必要的范围。我们建议您查看最大值有多大，并将 pad_length 设置为该值。

我怎么知道我是否需要 preserveNulls 提供的加密保障？

遗憾的是，答案是“看情况”。至少，应查看 Clean Rooms 加密计算 了解 preserveNulls 设置如何保护您的数据。但是，我们建议您参考组织的数据处理要求以及适用于相应协作的任何合同。

为什么我必须承担 base64 的开销？

为了与 CSV 等表格文件格式兼容，必须进行 base64 编码。尽管某些文件格式（例如 Parquet）可能支持数据的二进制表示，但重要的是，协作中的所有参与者都必须以相同的方式表示数据，以确保查询结果正确。

加密文字大小意外增加疑难解答

假设您加密了数据，结果数据的大小出人意料地大。以下步骤可以帮助您确定大小增加的位置以及可以采取的措施（如果有）。

确定大小增加的位置

在排查加密数据明显大于 cleartext 数据的原因之前，必须先确定大小的增加位置。可以放心地忽略 Cleartext 列，因为它们没有变化。查看其余的 fingerprint 和 sealed 列，然后选择一个看起来很重要的列。

确定大小增加的原因

fingerprint 列或 sealed 列可能会导致大小增加。

大小增加是否来自 fingerprint 列？

如果对存储增加贡献最大的列是 fingerprint 列，则可能是因为 cleartext 数据很小（例如，客户年龄）。生成的每个 fingerprint 加密文字的长度为 52 字节。不幸的是，在这个问题上无能为 column-by-column 力。有关更多信息，请参阅 fingerprint 列的基本开销 了解有关此列的详细信息，包括它如何影响存储要求。

导致 fingerprint 列中大小增加的另一个可能原因是协作设置 preserveNulls。如果禁用了 preserveNulls 的协作设置（默认设置），则 fingerprint 列中的所有 null 值都将变为 52 字节的加密文字。目前的协作对此无能为力。preserveNulls 设置是在创建协作时设置的，所有协作者必须使用相同的设置以确保查询结果正确。有关 preserveNulls 设置以及启用它会如何影响数据隐私保障的更多信息，请参阅 Clean Rooms 加密计算。

大小增加是否来自 sealed 列？

如果对存储增加贡献最大的列是 sealed 列，那么有一些细节可能会导致大小增加。

如果 cleartext 数据很小（例如，客户年龄），则生成的每个 sealed 加密文字的长度至少为 91 字节。遗憾的是，我们对这个问题无能为力。有关更多信息，请参阅 sealed 列的基本开销 了解有关此列的详细信息，包括它如何影响存储要求。

sealed 列存储增加的第二个主要原因是填充。填充会在加密 cleartext 之前向其添加额外的字节，以隐藏数据集中各个值的大小。我们建议您将数据集的填充设置为可能的最小值。至少必须将 fixed 填充的 pad_length 设置为包含列中可能的最大值。任何高于此值的设置都不会增加额外的隐私保障。例如，如果您知道列中可能的最大值可能为 50 字节，我们建议您将 pad_length 设置为 50 字节。但是，如果 sealed 列使用 max 填充，我们建议您将 pad_length 设置为 0 字节。这是因为 max 填充是指列中最大值之外的额外填充。

导致 sealed 列中大小增加的最后一个可能原因是协作设置 preserveNulls。如果禁用了 preserveNulls 的协作设置（默认设置），则 sealed 列中的所有 null 值都将变为 91 字节的加密文字。目前的协作对此无能为力。preserveNulls 设置是在创建协作时设置的，所有协作者必须使用相同的设置以确保查询结果正确。有关此设置以及启用它会如何影响数据隐私保障的更多信息，请参阅 Clean Rooms 加密计算。