在大学里，有人告诉我们，通过简单地将密钥与要签名的数据连接起来并通过哈希函数（例如$ s = \ mathrm {hash}（k || \ mathrm { data}）$或$ s = \ mathrm {hash}（\ mathrm {data} || k）$）。接下来提出的下一个想法是HMAC和CBC-MAC，它们要复杂得多（但是是标准化的）。

现在，我想知道以下“想法”的安全性是什么（我肯定有充分的理由为什么不使用它，因为它比HMAC或CBC-MAC更简单）：


计算哈希值$ h = \ mathrm {hash} （\ mathrm {data}）$。
计算密文$ c = \ mathrm {enc} _k（h）= \ mathrm {enc} _k（\ mathrm {hash}（\ mathrm {data}））$设置签名$ s = c $。

其中$ \ mathrm {hash} $是任意哈希函数，而$ \ mathrm {enc} $是任意对称块密码，使用密钥$ k $。

我找不到有关此类方案的任何陈述，也许我在错误的位置搜索了。但是，如果您可以帮助我解决该问题，那就太好了。

评论

与HMAC相比，它的性能肯定较差，这是由于此方案的抗碰撞性较低。特别是与HMAC兼容的128位MAC在您的方案中太弱了。
您还依靠密码的强度来进行加密和身份验证，因此，如果对分组密码进行非密钥公开攻击，则还可以注入数据包。使用HMAC，您只能读取流，除非可以恢复密钥。
请注意，hash（k || data）对于下一代哈希函数（包括所有SHA-3决赛入围者）都是安全的。
我还要质疑HMAC是否比目前的想法复杂得多。 $ Hash（K_1 | Hash（K_2 | Data））$是否真的比$ Encrypt（Hash（Data））$更复杂？
我有个问题。如果我的MAC是CBC操作模式下的hash = SHA-256且MAC = enc（hash（m））和enc = AES，那么它是安全的MAC吗？

#1 楼

不，通常来说，这是不安全的，除非您对加密方法进行了其他假设，而不是标准的隐私假设。

为了简单起见，隐私假设意味着给定密文$ C $，攻击者没有有关明文可能是什么的信息。但是，在您的情况下，我们并不在乎攻击者是否可以弄清楚加密功能的明文内容；我们还给了他数据，他可以自己计算$ hash（data）$。

我们关心的是（再次简化一下）攻击者，给定一条消息M和该消息的有效标签，则无法提出另一条消息以及该消息的有效标签。将其转化为您的建议，如果给了攻击者$ M $和$ E（Hash（M））$，他是否可以再选择一条消息$ M'$，并提出$ E（Hash（M'））$ ？

好吧，对于许多加密方法，他可以。例如，如果我们考虑在计数器模式下使用块密码，那么，如果在密文中翻转一位，则在明文中的相应位也会翻转。这意味着如果攻击者计算$ E（Hash（M））\ oplus Hash（M）\ oplus Hash（M'）$，那么结果恰好是$ E（Hash（M'））$，

我们需要为加密方法假设的其他属性是不可恶意攻击性；也就是说，给定$ M $和相应的加密$ E（M）$，攻击者无法修改加密，以便将其解密为任何其他特定消息。

在标准加密模式下，如果散列完全适合单个块输出，则ECB实际上是不可篡改的。鉴于128位哈希很容易受到冲突的影响（散列冲突是伪造的另一种方式），这意味着使用非标准的块密码（例如，具有256位块大小的Rijndael）。

认证的加密模式也是不可更改的。但是，这可能被视为作弊；经过身份验证的加密模式通过在内部有效使用MAC起作用；如果练习的目的是从其他加密原语创建一个加密原语，那么这样做就没有了。

评论

$ \ begingroup $
但是，如果我在CBC模式下使用128位块大小的块密码对256位哈希进行加密怎么办？对第一个（纯文本/密文）块的任何更改都会破坏第二个（纯文本/密文）块。但是，可以修改第二个而不影响第一个。有一个简单的解决方案。代替存储哈希的原始第一部分，可以将第一个纯文本块与第二个简单地进行异或。因此，对第二个进行的每次更改都会破坏第一个。这可能会进一步扩展（尽管我现在不确定）。这行得通吗？
$ \ endgroup $
– Anon2000
15年5月20日在12:01


$ \ begingroup $
刚注意到@pasgabriele在2013年问了类似的问题，但我想我的版本可能（或可能不会）更安全。
$ \ endgroup $
– Anon2000
15年5月20日在12:31
$ \ begingroup $
好吧，我不确定100％，但是可能存在问题：使用CBC，对第一个密文块进行一点更改只会在第二个明文块中创建一个更改，但是，使用PCBC可能会改善。
$ \ endgroup $
– Anon2000
15年5月20日在13:53


$ \ begingroup $
我发布了一个单独的问题，以更一般的方式评估此技术。
$ \ endgroup $
– Anon2000
2015年5月20日15:00
$ \ begingroup $
@ cooky451：为什么会失败？如果攻击者截获了原始的$（M，Mac）$，从而使接收者无法获得它，而是将其替换为$（M'，Mac'）$，该怎么办？
$ \ endgroup $
–雨披
2015年8月5日，12：48

#2 楼

事实证明，如果$ \ mathrm {enc}（\ cdot）$是安全的块密码（伪随机排列），并且如果$ \ mathrm {hash}（\ cdot）$具有抗碰撞性。

但是有一个陷阱。 （您只是知道必须有一个，不是吗？）

值得注意的是，典型的分组密码的分组宽度过窄，不足以确保安全。换句话说，当您尝试计算此构造提供的定量安全级别时，就会出现问题。例如，假设您使用AES作为$ \ mathrm {enc}（\ cdot）$和SHA1截断为128位（以匹配AES的128位块宽度）作为$ \ mathrm {hash}（\ cdot）$。好吧，那么您仅获得64位安全性。这容易受到大约$ 2 ^ {64} $的复杂性的冲突查找攻击。在检查了大约$ 2 ^ {64} $条消息之后，您期望找到一条消息$ m，m'$，这样，通过\ a简单的生日参数。

要确保不受此类攻击的影响，您需要一个哈希函数和块密码，其块宽度至少为160位。但是很少有现代分组密码支持这样的分组宽度-尤其是在定义HMAC的情况下。

因此，HMAC更适合当今通常可用的通用基元。


定义HMAC的第二个原因。 HMAC被设计为健壮的：最大程度地减少了对散列函数的假设。特别是，HMAC构造的设计使HMAC即使在偶然发现散列函数发生冲突攻击的情况下，也有机会保持安全的MAC构造。

事实证明这是一种有先见之明的设计策略。例如，MD5-HMAC被广泛使用-然后人们发现了对MD5可行的碰撞攻击。幸运的是，尽管MD5的耐碰撞性完全被破坏了，但MD5-HMAC似乎仍然是安全的：没人知道破坏它的方法。因此，HMAC的设计人员在使HMAC构造对哈希函数的某些类型的故障具有弹性方面非常成功。

相反，您的构造没有这种弹性。这是为什么人们可能更喜欢HMAC而不是您的构造的第二个原因。