我正在制作一个小型应用程序来加密文件,并遇到了在解密时验证提供的密钥是否正确的问题。我的想法是将(填充的,加密的)密钥与加密文件一起存储,因此当您要解密时,程序首先检查前几个字节(未填充的)是否等于提供的密钥。我不是安全专家,我看不出这种方法有问题,但我仍然觉得这在某种程度上是一种不好的做法。
从安全角度来看,这种方法可以吗?最初的问题可能已经有另一种解决方案了吗?
我正在制作一个小型应用程序来加密文件,并遇到了在解密时验证提供的密钥是否正确的问题。我的想法是将(填充的,加密的)密钥与加密文件一起存储,因此当您要解密时,程序首先检查前几个字节(未填充的)是否等于提供的密钥。我不是安全专家,我看不出这种方法有问题,但我仍然觉得这在某种程度上是一种不好的做法。
从安全角度来看,这种方法可以吗?最初的问题可能已经有另一种解决方案了吗?
虽然这里没有明显的漏洞,但更好的选择是简单地存储静态字符串,而不是密钥本身。如果攻击者发现允许他们发现一个明文块的侧信道攻击,您的方法会泄露密码,从而破坏整个系统,而固定文本选项则不会。
你可以这样做:
生成加密安全的随机 128 字节密钥
生成随机密钥的哈希
使用随机生成的密钥加密文件
使用用户提供的密钥加密随机密钥
将以下值放入文件中:
加密随机密钥:随机密钥哈希:加密文件数据
当要解密数据时,您使用用户提供的数据来解密加密的随机密钥,然后对其进行散列并与存储的散列进行比较。如果它们相同,则使用现在解密的随机密钥来解密数据。
包含一个静态字符串听起来好像很容易受到已知的明文攻击。相反,我会这样做(但很高兴听到这是一个坏主意!);
解密时,检查开头的哈希是否与您期望的哈希匹配。这使您能够检测您是否获得了正确的解密密钥,并且您还可以免费获得完整性检查。如果你想加快速度,假设你想加密大量数据,在整个有效负载上运行散列函数是不可行的,如果它是块密码,则将散列部分减少到几兆字节或块.
如果您将密钥本身的未加密哈希添加到文件中,攻击者可能会测试密钥而无需解密整个文件。这将大大加快攻击速度。