我用AES-256加密文件的软件有多安全？

Question

我正在做一个用AES在Java中构建文件加密软件的项目，它的操作非常简单，但我想知道它是否真的安全。

该程序提示用户输入密码对所选文件进行加密，输入密码后，使用Hmac 256的密钥派生函数PBKDF2对其进行安全保护，salt是8-byte SHA1 PRNG的伪随机数生成器，迭代量为100,000次，密钥长度为256位。

生成的安全密钥用于加密文件。AES的初始化向量是16 byte SHA1 PRNG的伪随机数生成器，文件现在被加密。

加密文件的前16个字节保存到IV中，在过去的8个字节中存储PBKDF2的盐分。

salt和IV不是随文件一起加密的，而是稍后添加的。这些操作安全吗？

Answer 1

第一:请不要翻动自己的密码。

如果您这样做是为了生产目的，我强烈建议您不要使用它。如果你想提高你的编程技能，或者这是一个微笑的研究项目，只要你不期望它有很强的(专业)安全性，这是很好的。

现在让我们来看看你在这里给出的那些可以改进的实际要点(按文章中的顺序排列)：

• PKCS#5 PBKDF2和HMAC-沙-256.请。PBKDF2是一个古老的基于密码的密钥派生标准，至少应该被bcrypt或更好的Argon2所取代。还请参阅我们关于密码散列的规范答案。。
• 100000次迭代请不要硬编码迭代计数，而是动态地在运行时找到它，这取决于CPU可以做什么。如果您不知道您的确切目标平台，并且您的软件将存在一段时间，则尤其如此。TrueCrypt也对这个问题很感兴趣.
• 8字节盐。虽然8字节(= 64位)的盐可能很好，但16字节(=128位)的盐是一个更好的选择，以防止计算前攻击有限的盐类。
• 沙一-PRNG.你没有透露这件事的任何细节。这看起来不错，但是如果可能的话，您应该升级( SHA-256或沙三)，以避免运行PRNG仍然可以使用的SHA-1，但是可能会对您使用这样一个老的和“破碎”算法的工具产生不好的影响。
• 16字节IV用于AES。注:这是CBC，CFB，CTR，OFB，……的适当选择。(即所有的未经认证的加密模式)它通常不是认证加密模式的适当选择，它需要一个12字节的值来保证最优的安全性。如果您能够保证唯一的键(看起来是可以的)，您可以让现在的默认值为“全零”。
• AES/CBC/PKCS5Padding。这是一个不错的选择(不是一个好的选择！)如果您有一些方法对消息进行身份验证(即确认消息没有被篡改)。您没有，所以更好的选择是使用认证的加密方案，如AES-GCM，AES-CCM，AES-EAX，.
• 相关数据(salt + IV)。首先，您可以让IV默认为某个值(全部为零？)如果您的文件保持较小(小于68 if )并使用AES-GCM。其次，您应该将该数据验证为“关联数据”，并在文件末尾添加一个身份验证标记(清空)(体面的库将自动这样做)。如果按原样使用，攻击者(谁知道第一个块)可以更改IV，使合法用户解密攻击者选择的明文。此外，您还希望将关键派生参数(如迭代计数、时间和空间参数以及其他配置)添加到关联数据中，以确保格式的长期适应性。