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

我实现了一种加密格式（以a和a的形式），它支持将多个密码流嵌套在一起。其目标是产生一种灵活的加密文件格式，即使是最偏执的用户也能满意。虽然我相信我已经收集了很多关于如何实现这样的东西的知识，但我不是一个深入的密码专家。背景：加密格式是用于，使用任何存储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字节salt，1k轮）为每个密码派生一个对称密钥
• 对称密钥用于加密文件；最多可在100个文件（约200 MB）中重复使用
• 密码算法是可配置的，但并非所有密码都允许：只有AES和Twofish（128/256位），只有经过身份验证的模式（目前只有GCM；没有ECB、CBC等）
• 密码是用随机初始化向量（IV）初始化的，IVs永远不会重复使用
• 多重密码算法可以嵌套/链接（1-n密码），例如AES-128和Twofish-256
• 密码配置、IVs和SALT通过HMAC（SHA256）认证

资料来源：

---

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

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

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

---

因此，不，这个方案不是特别安全。

这属于“隐蔽性安全”的总标题。在整个社区中使用单一密码会限制其用途。关键用例是单个用户在一对多机器上同步。和连接详细信息（到存储的信息无论如何都必须共享，例如FTP详细信息），因此在哑存储环境中必须完全信任。然而，这一点得到了应有的注意。一个多用户的概念是在列表中的高度一旦基本版本飞行。。。“隐蔽性安全”不是更适用于“试图隐藏机制”而不是“拥有对称密码”吗？它适用于依赖攻击者不知道该技术的任何技术，而不是加密密钥。一旦攻击者知道这项技术，即在本例中是密码序列，这并不比密钥更强大。这种解释会谴责所有基于密码的加密吗？你想说的是“密码是邪恶的”吗？胡说八道。这些都不是我在这里说过的。别把话塞进我的嘴里。我很感激你抽出时间给我一个详细的答案！我现在明白了该方案的弱点是密钥管理——特别是如果（如上所述）涉及到更多的用户。但是，假设只有一个用户或几个“受信任”用户，如果我遵循您的想法，即：创建主密钥（PBKDF2 w/1MM轮），并使用HKDF派生其他密钥，则该方案是否安全。这将使暴力（即使在HMAC上）变得不可行，对吗？当然，这仍然取决于密码的安全性。作为生成密钥的唯一秘密输入的错误或众所周知的密码始终是一个漏洞。但是，如果只有一个密码是唯一的选择，那么你就不能做得更好了。我知道单一密码并不是最好的选择，阅读你的评估，我一定会看看如何实现非对称方案（考虑到应用程序架构的其余部分）。目前，典型的用户便利性问题迫使我采用基于密码的方案。为了增加一点安全性，我计划严格限制密码，并检查基本的本地单词列表。