选择信标长度

我们的客户端加密库已重命名为 AWS 数据库加密 SDK。本开发人员指南仍提供有关 DynamoDB 加密客户端的信息。

当您向配置为可搜索加密的加密字段写入新值时，AWS 数据库加密 SDK 会根据明文值计算 HMAC。此 HMAC 输出与该字段的明文值进行一对一（1:1）匹配。HMAC 输出会被截断，以便多个不同的明文值映射到同一个被截断的 HMAC 标签中。这些碰撞或误报限制了未经授权的用户识别有关明文值的区别信息的能力。

为每个信标生成的平均误报数通过截断后剩余的信标长度决定。配置标准信标时，只需要定义信标长度。复合信标使用构造它们的标准信标的信标长度。

信标不会更改字段的加密状态。但是，当您使用信标时，查询的效率和泄露的有关数据分布的信息量之间存在内在权衡。

可搜索加密的目标在于，使用信标对加密数据执行查询，从而降低与客户端加密数据库相关的性能成本。信标与计算信标所依据的加密字段一同存储。这意味着，它们可以揭示有关您的数据集分布的区别信息。在极端情况下，未经授权的用户可能能够分析披露的有关您的分布的信息，并用它来识别字段的明文值。选择适当的信标长度可以帮助降低这些风险并保护分发的机密性。

查看您的威胁模型，以确定所需的安全级别。例如，有权访问您的数据库但不应访问明文数据的人越多，您就越想保护数据集分布的机密性。为了提高机密性，信标需要产生更多的误报。提高机密性会导致查询性能降低。

安全与性能

信标长度过长会导致产生的误报太少，并且可能会泄露有关数据集分布的区别信息。
信标长度过短会导出产生的误报太多，并且会增加查询的性能成本，因为它需要对数据库进行更广泛的扫描。

在确定适合解决方案的信标长度时，必须找到一个能够充分保护数据安全性且不会对查询性能产生超出绝对必要影响的长度。信标保留的安全程度取决于数据集的分布以及构造信标所依据的字段的相关性。以下主题假设您的信标分布均匀，并且其中不包含相关数据。

计算信标长度

信标长度以比特为单位进行定义，是指截断后保留的 HMAC 标签的位数。建议的信标长度因数据集的分布、相关值的存在以及您的特定安全和性能要求而异。如果您的数据集分布均匀，您可以使用以下方程和过程来帮助确定最适合您的实现的信标长度。这些方程仅会估计信标将产生的平均误报数，并不能保证数据集中的每个唯一值都会产生特定数量的误报。

注意

这些方程的有效性则取决于数据集的分布。如果您的数据集分布不均匀，请参阅信标是否适合我的数据集？。

通常情况下，您的数据集离均匀分布越远，您就越需要缩短信标长度。

估算总量

总量是指构造标准信标所依据的字段中的唯一值的预期数量，而不是字段中存储的值的预期总数。例如，考虑一个用于标识员工会议地点的加密 Room 字段。Room 字段预计将存储 100000 个总值，但员工只能预留 50 个不同的会议室用于会议。这意味着总量为 50，因为 Room 字段中只能存储 50 个可能的唯一值。

注意
如果您的标准信标由虚拟字段构造，则用于计算信标长度的总量是虚拟字段创建的唯一组合数。

在估算总量时，请务必考虑数据集的预计增长。使用信标写入新记录后，您将无法更新信标长度。查看您的威胁模型和任何现有的数据库解决方案，以估算您预计该字段在未来五年内将存储的唯一值的数量。

您的总量不需要很精确。首先，确定当前数据库中唯一值的数量，或者估算第一年预计存储的唯一值的数量。接下来，通过以下问题来帮助您确定未来五年内唯一值的预计增长情况。
- 您是否期望唯一值乘以 10？
- 您是否期望唯一值乘以 100？
- 您是否期望唯一值乘以 1000？
50000 和 60000 个唯一值之间的差异并不显著，两者都将产生相同的建议信标长度。但是，50000 和 500000 个唯一值之间的差异将显著影响建议的信标长度。

考虑查看常见数据类型（例如邮政编码或姓氏）出现频率的相关公共数据。举例来说，美国有 41707 个邮政编码。您使用的总量应与您自己的数据库成正比。如果数据库中的 ZIPCode 字段包含来自整个美国的数据，则即使 ZIPCode 字段当前没有 41707 个唯一值，也可以将总量定义为 41707。如果数据库中的 ZIPCode 字段仅包含来自单个州的数据，并且到目前为止仅包含来自单一州的数据，则可以将总量定义为该州的邮政编码总数，而不是 41704 个。
计算建议的预期碰撞次数范围

要确定给定字段的适当信标长度，您必须首先确定预期碰撞次数的适当范围。预期的碰撞次数表示映射到特定 HMAC 标签的唯一明文值的平均预期数量。一个唯一的明文值的预期误报数比预期的碰撞次数少一。

建议预期的碰撞次数大于或等于二，且小于总量的平方根。只有当您的总量具有 16 个或更多唯一值时，以下方程才有效。
```
2 ≤ number of collisions < √(Population)
```
如果碰撞次数少于两次，则信标产生的误报数将会太少。建议将两个作为预期碰撞的最小数量，因为这意味着，平均来说，字段中的每个唯一值都会通过映射到另一个唯一值来产生至少一个误报。
计算信标长度的建议范围

确定预期碰撞的最小和最大次数后，使用以下公式来确定适当信标长度的范围。
```
number of collisions = Population * 2^{-(beacon length)}
```
首先，求解信标长度，其中预期碰撞次数等于二（建议的最小预期碰撞数）。
```
2 = Population * 2^{-(beacon length)}
```
然后，求解信标长度，其中预期碰撞次数等于总量的平方根（建议的最小预期碰撞数）。
```
√(Population) = Population * 2^{-(beacon length)}
```
建议将此方程产生的输出向下舍入到较短的信标长度。举例来说，如果方程产生的信标长度为 15.6，则建议将该值向下舍入到 15 位，而不是四舍五入到 16 位。
选择信标长度

这些方程仅确定您的字段的建议信标长度范围。建议尽量使用较短的信标长度，以保护数据集的安全性。但是，您实际使用的信标长度却由您的威胁模型决定。在审查威胁模型以确定字段的最佳信标长度时，请考虑您的性能要求。

使用较短的信标长度会降低查询性能，而使用较长的信标长度则会降低安全性。通常，如果您的数据集分布不均匀，或者您根据相关字段构造不同的信标，则需要使用较短的信标长度来最大限度地减少泄露的有关数据集分布的信息量。

如果您查看威胁模型，并确定泄露的有关字段分布的任何区别信息不会对您的整体安全构成威胁，则可以选择使用比您计算的建议范围更长的信标长度。例如，如果将某个字段的建议信标长度范围计算为 9—16 位，则可以选择使用 24 位的信标长度来避免任何性能损失。

请谨慎选择信标长度。使用信标写入新记录后，您将无法更新信标长度。

示例

假设一个在加密操作中将 unit 字段标记为 ENCRYPT_AND_SIGN 的数据库。要为 unit 字段配置标准信标，我们需要确定 unit 字段的预期误报数量和信标长度。

估算总量

在审查了威胁模型和当前的数据库解决方案之后，预计 unit 字段最终将有 100000 个唯一值。

这意味着总量 = 100000。

计算预期碰撞次数的建议范围。

在此示例中，预期的碰撞次数应当介于 2—316 之间。


2 ≤ number of collisions < √(Population)


2 ≤ number of collisions < √(100,000)

```
2 ≤ number of collisions < 316
```

计算信标长度的建议范围。

在本示例中，信标长度应当介于 9–16 位之间。
```
number of collisions = Population * 2^{-(beacon length)}
```
1. 计算信标长度，其中预期的碰撞次数等于步骤 2 中确定的最小值。
```
2 = 100,000 * 2^{-(beacon length)}
```
  信标长度 = 15.6 或 15 位
2. 计算信标长度，其中预期的碰撞次数等于步骤 2 中确定的最大值。
```
316 = 100,000 * 2^{-(beacon length)}
```
  信标长度 = 8.3 或 8 位
确定适合您的安全和性能要求的信标长度。

对于低于 15 的每一个位，性能成本和安全性会翻一番。
- 16 位
  - 平均而言，每个唯一值将映射到 1.5 个其他单位。
  - 安全性：具有相同的截断 HMAC 标签的两条记录具有相同明文值的可能性为 66%。
  - 性能：查询将针对您实际请求的每 10 条记录检索 15 条记录。
- 14 位
  - 平均而言，每个唯一值将映射到 6.1 个其他单位。
  - 安全性：具有相同的截断 HMAC 标签的两条记录具有相同明文值的可能性为 33%。
  - 性能：查询将针对您实际请求的每 10 条记录检索 30 条记录。

Javascript 在您的浏览器中被禁用或不可用。

要使用 Amazon Web Services 文档，必须启用 Javascript。请参阅浏览器的帮助页面以了解相关说明。

文档惯例

选择信标类型

选择信标名称