我正在使用命令根据密码加密和解密文件：
openssl aes-256-cbc -a -salt -in secrets.txt -out secrets.txt.enc --pass pass:mypassword
和
openssl aes-256-cbc -d -a -in secrets.txt.enc -out secrets.txt.new -pass pass:mypassword
有人提到这可能容易受到暴力攻击（尝试通过密码解密文件）。
有没有比这更安全/更好的使用密码加密文件的方法？还提到了 -pbkdf2 选项，但我似乎找不到太多相关信息。
我印象中，带盐的 AES-256 是使用密码加密文件的一个非常好的选择。
如果密码很长而且非常复杂，这是否也能起到帮助作用？
答案1
这最好的选择？不要使用 openssl，而应使用 gpg
显然你的命令使用了该enc命令（尽管 openssl 的手册页根本没有提到aes-256-cbc，并且openssl help输出到 stderr，因此简单地将它传输到 less 是一项苦差事，另外仅供参考它有一个未记录的-v功能）并且它离开很多有待改进，请参阅我的其他答案了解更多详细信息，但它们基本上是：
- 非标准加密格式。
- 没有指明加密算法；你应该自己跟踪它。
密码和盐转换成密钥和 IV 的过程没有记录，但查看源代码可以发现它调用 OpenSSL 特定的EVP_BytesToKey()函数，它使用自定义密钥导出函数经过一些重复的哈希处理。这是一个非标准且未经充分审查的构造（！），它依赖于声誉可疑的 MD5 哈希函数（！！）；该函数可以在命令行上使用以下命令进行更改未记录的
-md标志（!!!）；“迭代计数”由命令设置enc为1并且无法更改（！！！！）。这意味着密钥的前 16 个字节将等于MD5(密码||盐)，就这样。这太弱了！任何知道如何在 PC 上编写代码的人都可以尝试破解这种方案，并且每秒可以“尝试”几千万个潜在密码（使用 GPU 可以实现数亿个）。如果您使用“openssl enc”，请确保您的密码具有非常高的熵！（即高于通常建议的；至少要达到 80 位）。或者，最好根本不使用它；而是选择更强大的东西（基努在对密码进行对称加密时，使用更强的 KDF 并对底层哈希函数进行多次迭代）。
GPG 已经经过了几十年的安全测试使用，所有简单的错误都已被避免/修复，并且如果使用得当，可以难倒一个世界主要超级大国。