recordbox

欢迎使用 recordbox 🎉

这个crate提供了一个简单的API来加密 id:payload 样式的记录，例如网络数据包或文件等。

为什么？

记录相当常见，通常由两个主要元素组成

1. 一个ID，用于标识/定位记录；例如文件名或序列号（即使是非显式的）或条目UUID等。
2. 相关的有效负载

这个crate提供了一个简单且统一的API来加密记录有效负载，并将生成的密文与记录ID绑定，这样你就不必每次都自己实现这些基础功能。

加密

有三种不同类型的盒式；哪一种最好取决于您的用例

Recordbox

最通用的格式是 Recordbox。它通过使用SIV实现，使用ID作为关联数据和一个固定的nonce。

优点

• 弹性：由于SIV构造的性质，对于不同的记录负载重复使用记录ID是完全可行的。如果记录ID不是唯一的（例如，文件名），这非常有用，并且如果您的实现无法保证记录ID永远不会被重复使用，它还可以提供额外的安全边界。
• 通用性：您基本上可以使用任何类型的记录ID和有效负载与此盒式一起使用。
• 确定性：由于相同的ID+明文组合总是产生相同的密文，因此可以轻松实现快速反向查找，以及随后的去重等操作。

缺点

• 非随机化：由于实现使用固定的nonce，相同的ID+明文组合总是产生相同的密文。这可能会泄露有关相同记录的信息，并在某些情况下足以完全破坏一个协议。
• 慢：大多数（如果不是所有）当前的SIV构造都比例如AES-GCM慢得多。尽管在大多数情况下这不是问题，但在某些设置中可能成为致命缺陷。

UniqueRecordbox

UniqueRecordbox 是一个随机记录盒式，它使用记录ID作为（间接）nonce。它通过从提供的密钥和记录ID以及确定性的或固定的nonce中导出一个特定的记录子密钥来工作。这类似于XChaCha构造，并允许使用任意长的记录ID（只要它们对每个记录负载都是唯一的）。

优点

• 通用性：您基本上可以使用任何类型的记录ID和有效负载与此盒式一起使用。
• 快速（适用于大型记录）：因为这个盒子允许使用简单的AEAD构造，通常比使用SIV构造加密大型记录负载要快得多。

缺点

• 脆弱：因为密钥直接从记录ID派生，你绝对不能为不同的记录负载重用记录ID。在某些情况下，这已被证明相当困难；特别是如果你无法实现可靠的单调计数器或创建足够大的随机记录ID。
• 慢（适用于小型记录）：因为这个盒子使用相当昂贵的子密钥推导，如果你需要处理大量小型记录负载，它可能不是最佳选择。

注意

这是一个后备方案，因为到目前为止，SIV实现并不是在每种语言中都容易获得。然而，在大多数情况下，如果你能承担一些额外的CPU周期，你可能应该使用Recordbox，如果性能至关重要，则使用FastRecordBox。

FastRecordBox

FastRecordBox是一个随机记录盒子，它直接将记录ID映射到一个nonce（即不派生特定的记录子密钥）。

优点

• 快速：因为这个盒子不执行任何昂贵的子密钥推导，并允许使用简单的AEAD构造，这是可用的最快的盒子方案。
• 相当常见：在底层，这个方案通常转换为一个直接调用AEAD构造，这使得如果需要，很容易自己实现它。

缺点

• 脆弱：因为nonce直接从记录ID创建，你绝对不能为不同的记录负载重用记录ID。这在某些情况下已被证明相当困难；特别是如果你无法实现可靠的单调计数器。
• 仅限短记录ID：通常nonce相当短（8到12字节）。因此，为了避免冲突，必须从每个Self到nonce有一个注入映射。这也意味着你的记录ID通常不能大于8到12字节。

待办事项

• 为RecordBox提供实现
• 为UniqueRecordBox提供实现
• 为FastRecordBox提供实现