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

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 column

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

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

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

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

故障排除 fingerprint 列

为什么密文在我的 fingerprint 列的大小比大小大几倍 cleartext 里面有那个吗？

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

为什么密文在我的 fingerprint 列比大小小几倍 cleartext 里面有那个吗？

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

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

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

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

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

Sealed 列

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

基本开销 sealed 列

有基本开销 sealed 列。这种开销是恒定的，除了 cleartext 和填充（如果有）字节。

在进行任何加密之前，数据在 sealed columns 前面有一个 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 的填充类型

选择 pad 类型none不会为填充添加任何填充 cleartext 并且不会为前面描述的基本开销增加额外的开销。没有填充会产生最节省空间的输出大小。但是，它不提供与 fixed 和 max 填充类型相同的隐私保障。这是因为底层证券的规模 cleartext 从密文的大小中可以看出。

fixed 的填充类型

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

鉴于填充已添加到 cleartext 在加密之前，AES-GCM 有一对一的映射为 cleartext 变为密文字节。base64 编码将增加 33%。填充物的额外存储开销可以通过减去填充物的平均长度来计算 cleartext 从的值中pad_length乘以 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 column

以下是一组输入和输出数据的示例 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 里面有那个吗？

这取决于多个因素。首先，a中的密文 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 列，然后选择一个看起来很重要的列。

确定大小增加的原因

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

尺寸增加是否来自 fingerprint 专栏？

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

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