Encryption 使用弱密码bcrypt或SHA-256+加密文件；AES-256？

我从一个弱密码（8个小写字符代表ex）和一个文件开始。我需要用那个密码加密那个文件。结果必须是针对已知攻击的安全

方法1：我可以使用SHA-256对密码进行散列，然后使用生成的散列和文件作为AES-256的输入，给我一个加密文件。我知道SHA-256和AES-256都非常快。这不会使文件容易受到暴力攻击吗

例如，可以获取一个彩虹表，其中包含预先计算的SHA-256哈希值，并假设它是一个非常小的文件和一个非常弱的密码，尝试在合理的时间内（使用专用硬件几个月）使用该表中的每个哈希值对AES-256进行解密

方法2：使用bcrypt。如果我理解正确的话，bcrypt比SHA-256+AES-256更适合加密文件，因为它的密钥生成方案有一个功因子，可以产生更强的密钥。还是我错了

我看到的Ruby和Python实现（wrappers？）侧重于使用bcrypt作为密码的哈希方案，而不是密码本身。我甚至可以使用bcrypt在“一步”中散列弱传递并加密文件吗

方法3：使用bcrypt散列传递，使用该散列和文件作为AES-256的输入，给我加密的文件。这就解决了“密钥太快而无法生成”的问题。（假设这是一个问题。）然而，bcrypt哈希的长度为448位，AES-256需要256位密钥。简单的解决方案是删除散列的尾随位，并将其用作AES-256的密钥。我不会走这条路，因为我对密码学了解不够，不知道会产生什么后果

编辑：我不能盐通过，因为这是一个离线应用程序。没有合理的地方存放盐。我可以在通行证上加盐，并将未加密的盐与加密文件一起存储。如果数据库被破坏，盐几乎本质上是公开/可见的。盐的作用是防止彩虹桌攻击。感谢Nemo，贝娄。

方法4：使用（PBKDF2从密码中导出密钥+使用该密钥进行加密的您选择的密码），最好是其他人的实现

---

别忘了盐。（您将其与加密数据一起存储。它只需要8个字节左右。）

所有这些听起来都是个坏主意。如果你从弱密码开始，你所应用的任何转换仍然会产生弱密码，因为它们可能是已知的或依赖于模糊性。我想问题是，当用户不顾所有建议，决定使用弱密码时，我们能提供的最多是什么。我不想要求密码带有符号和大写等等，因为人们通常会忘记它们。把这个决定留给用户，而不是强迫他们使用较弱的密码，怎么样？我在哪里说过我打算强迫用户使用较弱的密码？相反，我正在搜索一个即使密码很弱也相当强的方案。我认为已知的salt根本不是salt。你想错了：-）。根据定义，盐几乎是公开的。有关更多信息，请参阅。你是对的。这和我几个月前在研究密码散列方案时得出的结论是一样的，但现在，我开始说出我刚才所说的。[拍打额头]我的大脑开始变得一团糟的迹象谢谢因为它是使用广泛使用的密码原语的广泛使用的标准。例如，SHA-256比河豚接受了更多的分析，这使得它在大多数人看来“更安全”。但据我所知，两者都没有被破解。（使用标准还可以提高可维护性；将来人们更容易找到其他平台的实现，如果这是一个问题的话。）我已经阅读了PKCS#5文档，我认为这正是我想要的。据我所知，为了符合标准，可以使用PBKDF2生成256位密钥，然后将该密钥与AES-256一起使用。PBKDF2本身可以使用各种伪随机函数，如HMAC-SHA-1。在python中，可以使用这个模块：与PyCrypto相同的作者。从源代码看，HMAC-SHA1用于伪随机函数。