#加密密钥 #私钥 #密钥存储 #雾工具

雾加密

使小、独立字节数组的签名和加密更容易的实用程序。主要用例是雾打包库。

12 个版本

0.5.3 2023 年 8 月 27 日
0.4.3 2023 年 2 月 9 日
0.4.2 2022 年 1 月 24 日
0.4.1 2021 年 9 月 5 日
0.4.0 2021 年 3 月 14 日

#809密码学

Download history 25/week @ 2024-03-10 45/week @ 2024-03-31 2/week @ 2024-04-07

每月 127 次下载
用于 3 crates

MIT/Apache

295KB
5.5K SLoC

雾加密

Build License Cargo Documentation

一个简单的以存储为导向的加密库,为您提供选择自由。它支持散列、公钥签名、公钥和对称密钥加密、密钥导入/导出以及基本的密钥存储。

正确实现密码学可能很困难。该库通过仅提供少量密码学原语、对密码学算法及其实现做出强决策,并尝试限制最终用户可能做出的不良行为数量,来尝试使事情变得简单。更改算法应不常见,并遵循计划流程(见密码学版本控制)。优点在于,很难以泄露秘密和损害安全的方式误用此库。缺点在于,此库主要针对与存储数据一起使用,而不是通信协议,并且不支持任何不寻常的密码学操作。强制使用单个首选算法集也大大限制了硬件兼容性。

用户指南

你可能不应该直接使用此库。相反,库的部分内容应由保险库的实现者导出,你应该使用这些。或者,你可能通过 fog-pack 使用它,该库也导出了此库的部分内容。你可以期待看到以下原语

通用

  • Vault:一个可以保存你的加密密钥的结构。

散列

  • Hash:一系列字节的加密散列。
  • HashState:一个结构,用于迭代添加字节以创建一个 Hash

签名

  • Signature:一个验证过的 Hash 的加密签名。
  • UnverifiedSignature:尚未验证的加密签名。
  • IdentityKey:用于签名散列的私钥。
  • Identity:公钥身份,用于指示哪个 IdentityKey 创建了给定的 Signature

对称密钥加密

  • StreamKey:用于加密和解密数据的共享对称密钥。
  • StreamId:一个公开的唯一标识符,用于指示应该使用哪个 StreamKey 解密加密数据。

公钥加密

  • LockKey:用于解密数据的私钥。
  • LockId:一个公钥,用于指示应使用哪个 LockKey 来解密加密数据。

加密存储

  • IdentityLockbox:一个加密容器,用于存储一个 IdentityKey
  • StreamLockbox:一个加密容器,用于存储一个 StreamKey
  • LockLockbox:一个加密容器,用于存储一个 LockKey
  • DataLockbox:一个加密容器,用于存储字节数组。

保险库实现指南

首先,重新导出用户指南中列出的结构。如果您的保险库完全由软件组成,您可能想使用各种 ContainedXXX 结构来存储密钥,并将它们通过导出一些主密钥来存储。避免让密钥以未加密的形式存在。您可以通过获取一个32字节的随机字节序列,在其前面添加一个1(版本字节),并使用 ContainedStreamKeytry_from 实现来封装序列来创建主密钥。确保在这样做之后将主密钥归零!

如果您的保险库具有硬件或操作系统组件,您的硬件保险库可能在其存储所有类型密钥的能力方面受到限制。在这种情况下,您将需要有一个软件端实现来弥补缺失的存储。这里推荐的方法是实际上在创建时接受一个纯软件保险库的引用,并让它处理任何不支持的运算。然后,您的保险库可以捕获它所支持的所有操作。

或者,如果您的硬件/操作系统组件支持的功能集非常小,无法执行任何类型的密钥导入/导出,并且旨在处理高风险场景,考虑完全不实现保险库特性。相反,创建自己的密钥存储接口,并为仅支持的接口提供支持者实现(您的选项为 SignInterfaceStreamInterfaceLockInterface)。

使用的加密算法

目前使用的算法有

  • 哈希:使用32字节摘要的Blake2B
  • 签名:Ed25519与“严格”验证
  • 对称加密:使用XChaCha20和Poly1305的AEAD加密算法。
  • Diffie-Hellman密钥交换:X25519

加密版本管理

这个库有4个核心加密算法,这些算法可能随着时间的推移而升级

  • 哈希算法
  • 签名算法
  • 对称加密算法(包括批量加密、AEAD构建和HMAC)
  • Diffie-Hellman(DH)密钥交换算法(用于使用公钥加密数据)

升级应该很少发生,并且在大约一个现有推荐算法被认为较弱但尚未被破坏时进行。

理想的升级过程是

  1. 选择一个新的算法来替换现有的一个。
  2. 实现新的算法。相关的MAX_VERSION常量增加。
  3. 部署1年后,相关的DEFAULT_VERSION常量增加。这为库用户提供了时间来支持新算法,而不会破坏非更新的部署。
  4. 再过2年,相关的MIN_VERSION常量增加。这为库用户提供了时间来在所有部署中增加默认版本,然后按需升级所有现有存储的数据。

这是最佳情况下的升级场景。如果认为现有算法已被破坏,DEFAULT_VERSION和MIN_VERSION将尽快增加。“破坏”在这里意味着有资金的攻击者有可能破坏该算法。当安全性受到破坏时,与已部署代码的兼容性中断被视为可接受的选择。

我们几乎肯定会在未来升级签名和DH交换算法,因为我们需要迁移到后量子算法。对于哈希和对称加密算法,没有类似的即将到来的威胁。

依赖项

~2.7–4MB
~82K SLoC