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 在 密码学
每月 127 次下载
用于 3 crates
295KB
5.5K SLoC
雾加密
一个简单的以存储为导向的加密库,为您提供选择自由。它支持散列、公钥签名、公钥和对称密钥加密、密钥导入/导出以及基本的密钥存储。
正确实现密码学可能很困难。该库通过仅提供少量密码学原语、对密码学算法及其实现做出强决策,并尝试限制最终用户可能做出的不良行为数量,来尝试使事情变得简单。更改算法应不常见,并遵循计划流程(见密码学版本控制)。优点在于,很难以泄露秘密和损害安全的方式误用此库。缺点在于,此库主要针对与存储数据一起使用,而不是通信协议,并且不支持任何不寻常的密码学操作。强制使用单个首选算法集也大大限制了硬件兼容性。
用户指南
你可能不应该直接使用此库。相反,库的部分内容应由保险库的实现者导出,你应该使用这些。或者,你可能通过 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(版本字节),并使用 ContainedStreamKey
的 try_from
实现来封装序列来创建主密钥。确保在这样做之后将主密钥归零!
如果您的保险库具有硬件或操作系统组件,您的硬件保险库可能在其存储所有类型密钥的能力方面受到限制。在这种情况下,您将需要有一个软件端实现来弥补缺失的存储。这里推荐的方法是实际上在创建时接受一个纯软件保险库的引用,并让它处理任何不支持的运算。然后,您的保险库可以捕获它所支持的所有操作。
或者,如果您的硬件/操作系统组件支持的功能集非常小,无法执行任何类型的密钥导入/导出,并且旨在处理高风险场景,考虑完全不实现保险库特性。相反,创建自己的密钥存储接口,并为仅支持的接口提供支持者实现(您的选项为 SignInterface
、StreamInterface
和 LockInterface
)。
使用的加密算法
目前使用的算法有
- 哈希:使用32字节摘要的Blake2B
- 签名:Ed25519与“严格”验证
- 对称加密:使用XChaCha20和Poly1305的AEAD加密算法。
- Diffie-Hellman密钥交换:X25519
加密版本管理
这个库有4个核心加密算法,这些算法可能随着时间的推移而升级
- 哈希算法
- 签名算法
- 对称加密算法(包括批量加密、AEAD构建和HMAC)
- Diffie-Hellman(DH)密钥交换算法(用于使用公钥加密数据)
升级应该很少发生,并且在大约一个现有推荐算法被认为较弱但尚未被破坏时进行。
理想的升级过程是
- 选择一个新的算法来替换现有的一个。
- 实现新的算法。相关的MAX_VERSION常量增加。
- 部署1年后,相关的DEFAULT_VERSION常量增加。这为库用户提供了时间来支持新算法,而不会破坏非更新的部署。
- 再过2年,相关的MIN_VERSION常量增加。这为库用户提供了时间来在所有部署中增加默认版本,然后按需升级所有现有存储的数据。
这是最佳情况下的升级场景。如果认为现有算法已被破坏,DEFAULT_VERSION和MIN_VERSION将尽快增加。“破坏”在这里意味着有资金的攻击者有可能破坏该算法。当安全性受到破坏时,与已部署代码的兼容性中断被视为可接受的选择。
我们几乎肯定会在未来升级签名和DH交换算法,因为我们需要迁移到后量子算法。对于哈希和对称加密算法,没有类似的即将到来的威胁。
依赖项
~2.7–4MB
~82K SLoC