在实际使用密钥之前检查它

Question

我有一个数据块加密使用双密钥128位。

数据必须从GUI访问，用户给出密钥，块被解码，真实的数据被访问。

问题是，在尝试解码块之前，我需要确保密钥是正确的。

我目前的解决方案是有一个文件(比如chk.blk)，它是对一些数据的加密，我可以用来测试密钥的正确性。

最初，我有一个文件chk.blk是对已知数据(比如文本12345678)的加密，然后我认为这可能会危及密钥。这是真的吗？如果攻击者同时拥有原始数据和加密数据，那么双重攻击中是否存在缺陷？

由于担心会出现这种情况，我现在生成一个具有给定属性的随机文本(例如，x...x..x，其中.是与x不同的任何字符)。我获取密钥，解码chk.blk并验证结果是否具有所需的属性。这个想法是，现在攻击者没有已知的文本可以使用，而是相当大的一组文本。当然，我不能确定这个键是否真的是正确的，用户可能会偶然地获得一个密钥，该键产生一个具有所需属性的解码文本，但我认为这个概率非常低。你认为这种方法有什么问题吗？

有什么建议吗？

使用场景

我在这里添加了一些更多的信息，以澄清预期的用法。

假设您有一组相当大的文档(5Mb数据)，这些文档必须发送给大量收件人(比如10.000)。这些文件必须绝对保密，直到指定的日期/时间(例如2012年12月21日21:12)。

从现在到那时，所有的接收者将能够下载文件和他们的电脑上的解密程序。他们将到达指定的目的地，并在适当的时间等待接收解码密钥。

精确的同步并不重要，但它们都必须(几乎)同时阅读文档。

他们中的任何一个都不能在指定日期之前阅读文件，这是绝对强制性的。

他们将位于他们可能无法连接到互联网的地方，这就是他们必须事先下载文档的原因。

然而，他们都能收到带有密钥的消息(例如，通过短信、电话、电视频道或无线电数字站广播，.)。

因此，我们的想法是分发包含128位安全性的文档，这应该足以保护密钥几个月，然后将密钥作为字符串(26个字符)分发。

Answer 1

为了使对称分组密码按现代标准被认为是安全的，它必须是IND-CPA，在所选的纯文本攻击下，这与随机预言是无法区分的。它还必须是IND和IND 2，但IND也足以使它在已知的纯文本攻击下安全。

假定TwoFish仍未中断，因此使用单个已知块的密码文本作为关键验证器应该是安全的。或者，更准确地说，将该chk.blk文件与加密文件一起存储将不会显着地显示有关密钥的更多信息。

但是，您可能已经或可能还没有意识到您的方法存在其他问题。

首先，你真的认为让用户使用GUI输入一个完全随机的128位密钥是可行的吗？大多数应用程序在这样的场景中使用pass短语，在这种情况下，您的方法应该略有不同。首先，您把PBKDF的盐存储在哪里？密钥将用于加密多个文件吗？通过查看已知使用相同密钥加密的两个文件的密码文本，对手将能够推断出哪些信息？

其次，只有在唯一的威胁是对手的情况下，您的方法才是真正安全的，它没有访问密钥，而是只访问验证器和实际密码文本，试图猜测与密码文本对应的纯文本内容。您的计划不足以防止任何超出这种情况的事情发生。

Answer 2

鉴于您的具体问题，我建议在您的有效载荷中嵌入一个MIC。消息完整性代码是嵌入在消息中的检查和，并与消息一起加密。你不必使用安全散列，它可以是任何东西。我更喜欢Fnv1，因为它实现起来很简单。

check块的问题是攻击者知道检查消息的内容，检查消息的大小很小，因此攻击者可以使用较小的消息作为较大攻击的代理。较小的消息需要较少的时间来解密。

对于MIC，必须使用候选密钥对消息的整个内容进行解码，然后计算MIC。这给攻击者增加了额外的计算负担。

你可能已经想到了这一点，这让我怀疑解密代码是否不在你的控制范围之内。