0

我实现了一种加密格式（以MultiCipherOutputStream和MultiCipherInputStream的形式），它支持将多个密码流相互嵌套。目标是产生一种灵活的加密文件格式，即使是最偏执的用户也能满意。虽然我相信我已经收集了很多关于如何实现这样的东西的知识，但我并不是一个深入的加密专家。背景：加密格式适用于Syncany，这是一种使用任意存储的 Dropbox 式文件同步工具。

所以我的问题是：

  • 这种加密格式的概念在密码学上是否合理？
  • 我的任何假设和设计概念是否错误或有问题？
  • 是否正确实施？

以下是格式说明：

Length       HMAC'd           Description
----------------------------------------------
04           no               "Sy" 0x02 0x05 (magic bytes, 4 bytes)
01           no               Version (1 byte)
12           no               Header HMAC salt            
01           yes (in header)  Cipher count (=n, 1 byte)

repeat n times:
  01         yes (in header)  Cipher spec ID (1 byte)
  12         yes (in header)  Salt for cipher i (12 bytes)
  (dyn.)     yes (in header)  IV for cipher i (cipher specific length, 0..x)    

32           no               Header HMAC (32 bytes, for "HmacSHA256")
(dyn.)       yes (in mode)    Ciphertext (HMAC'd by mode, e.g. GCM)

一般设计概念和假设：

  • 假设：所有用户共享一个密码
  • 输入参数：密码字符串、密码规范列表（例如 AES/GCM/NoPadding、128 位）
  • 密码用于使用 PBKDF2（12 字节盐，1k 轮）为每个密码派生一个对称密钥
  • 对称密钥用于加密文件；它在最大重复使用。100 个文件 (~ 200 MB)
  • 密码算法是可配置的，但并非所有密码都被允许：只有 AES 和 Twofish（128/256 位），只有经过身份验证的模式（目前只有 GCM；没有 ECB、CBC 等）
  • 密码使用随机初始化向量 (IV) 进行初始化，IV 永远不会重复使用
  • 可以嵌套/链接多个密码算法（1-n 密码），例如 AES-128 和 Twofish-256
  • 密码配置、IV 和盐使用 HMAC (SHA256) 进行身份验证

资源：

4

1 回答 1

2

正如 EJP 已经规定的那样，您的方案在密钥管理方面不是很安全。执行此操作的常用方法是使用非对称密钥，例如 PGP 密钥分发方案。目前只有一个人必须泄露密码，使这个方案不安全，没有人知道谁是罪魁祸首。

此外，相同的密码用于派生密钥。现在我假设这些密钥之一用于计算标头上的 HMAC。这意味着，如果对密码进行字典或暴力攻击是可行的，则可以通过标头检查 HMAC 的结果。一旦找到密码，就可以从中派生出其余的密钥。

因此，尽管您有多层加密，但您的密钥/密码管理方案中没有多层。攻击可能只会集中在您的密钥管理方案上，从而使您额外的几轮加密变得多余。实际上，最初使用具有更大盐和迭代计数的 PBKDF，然后在 PBKDF 的结果上使用 KBKDF 派生密钥，实际上已经更安全了。但即使这样也不会隐藏密钥管理的问题。

所以不，这个方案不是特别安全。

于 2013-11-05T23:57:33.710 回答