Question

我实现了一种加密格式（以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）

来源：

Answer 1

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

此外，使用相同的密码来导出密钥。现在我假设其中一个键用于计算标题上的HMAC。这意味着如果字典或暴力攻击对密码是可行的，则可以通过标头针对HMAC检查结果。找到密码后，可以从中导出其余密钥。

因此，虽然您有多层加密，但您的密钥/密码管理方案中没有多个层。攻击可能只关注您的密钥管理方案，使您的额外轮次加密变得多余。实际上，使用具有较大盐和迭代计数的PBKDF实际上已经更安全了，然后使用KBKDF在PBKDF的结果上导出密钥。但即使这样也无法掩盖密钥管理的问题。

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

这种基于Java的多密码加密格式实现是否安全？

1 个答案: