在长密码的情况下，基于密码的密钥推导有多安全？

Question

我正在加密设备中的文件并将其存储起来。所以我需要在设备的整个生命周期中保持相同的密钥。对于密钥派生，我使用EVP_比睾酮() of OpenSSL。

基于密码的密钥派生(PBKD)中的问题是，如果密码来自用户，攻击者可以猜出密码。但在我的例子中，我使用一些长的基于系统的数字(而不是来自用户)作为密码。这条路对吗？

修改我代码中的加密密钥(例如左移或右移密钥)对安全性有帮助吗？

如何将盐存储在代码中(硬编码)？

Answer 1

基于密码的密钥派生(PBKD)中的问题是，如果密码来自用户，攻击者可以猜出密码。但在我的例子中，我使用一些长的基于系统的数字(而不是来自用户)作为密码。这条路对吗？

密码是“用户大脑中的秘密密钥”。密钥的主要属性是它的保密性，它是衡量攻击者不知道的程度的一种方法。一般来说，攻击者都是超级聪明的，所以他们唯一不知道的就是纯粹的随机性。

密码的主要问题是人类的大脑不善于存储随机性(它们在产生随机性方面也很差)。这就是密码薄弱的原因:攻击者可以尝试通过“猜测”找到密码，这基本上意味着尝试所有与人兼容的随机性的组合。

PBKDF2和其他密码散列函数一样，通过使每个猜测都变得更昂贵(对攻击者和普通用户来说)，从而使密码的弱点变得更容易容忍。

如果在您的应用程序中，密码实际上不是由用户输入的，而是由机器输入的，那么您可以使用具有很大随机性的“密码”(机器比人类更好地记住长序列的随机数)，此时密码散列可能会变得非常无用。

修改我代码中的加密密钥(例如左移或右移密钥)对安全性有帮助吗？

它的帮助就像在你的头上用茶壶跳舞一样，同时高唱着Huitzilopochtli的荣耀将帮助你猜出下一个中奖的彩票号码。

(如果Huitzilopochtli真的对你的仪式感到好笑，他可能会给你一些好处，但他并不是以幽默感著称。)

如何将盐存储在代码中(硬编码)？

salt与密码散列结合起来是有意义的:它是可以容忍密码(本质上是弱的，见上面)的方法之一。如果您的“密码”不是真正的密码，那么密码哈希和salt就无关紧要了。

相反，当一个盐是相关的，那么它的主点和唯一点永远不会被重用

因此，可以说，根据上下文的不同，硬编码盐值要么是错误的想法，要么是非常糟糕的想法。

Answer 2

请记住，物理安全和逻辑一样重要，如果您的硬件相对安全(或繁重)，并且担心硬盘被盗和解密，那么使用诸如序列号之类的硬件信息(至少有两个--我相信您已经在这样做了)--这样，如果没有正确的硬件，驱动器就无法解密。

至于额外的层和盐，只需确保您混淆您的加密和解密脚本和硬编码盐应该是好的。

显然，我在您的场景中并不是100%，但是在您的情况下，取决于加密、解密等的工作方式，取决于一个可行的salt，如果您可以在某种程度上使每个文件具有特定的salt动态，这意味着即使他们窃取了硬件并猜测了一个文件盐分，他们也无法解密其余的文件。

如果我知道场景的细节，我可能可以给你一些建议，但有时你不应该分享一些信息(社会工程)

我希望这能激发一些想法。

Answer 3

只有在密码本身可能弱的情况下，才需要增强密码的KDF。最主要的例子是人类产生了它。

KDF将多次迭代密码哈希。这意味着获得密码哈希访问权限的攻击者必须迭代每个密码猜测次数，从而减缓攻击速度。这与没有KDF的强密码具有相同的效果。这是因为具有更大熵的密码所具有的额外密钥空间可以替换额外的散列迭代，以计算中断所需的时间。

因此，计算机生成的密码不需要用于键拉伸的KDF，因为它可以单独生成一个具有足够强度的密钥。如果可能的话，获取128位熵，由加密安全的随机数生成器(CSPRNG)生成。

关于盐-你不需要盐。128位将足以保护密码免受本质上的哈希攻击。彩虹表覆盖整个128位密钥空间将是不可能的大。