$$（k，m）\ mapsto \ mathcal {C}（k，m）= \ mathcal {H}（m \ mathbin \ | k） $$
，其中$ \ mathbin \ | $表示串联，$ k $是密钥（恒定或至少固定大小），而$ m $是消息（长度可变）。假设对手可以（迭代）使用$ m_j $提交查询并获得$ C（k，m_j）$，并且想要获得$ k $或以其他方式为$ m \ ne m_j计算$ C（k，m）$ $。
，MAC $ \ mathcal {C} $确实不错。特别是，如果$ \ mathcal {H} $与Random Oracle模型中的随机函数没有区别，则$ \ mathcal {C} $是安全的。即使$ \ mathcal {H} $可能具有length-extension属性，它也不会对$ \ mathcal {C} $造成破坏性的攻击。<br />
我认为不太实际的通用攻击可以看到，如果以$ \ mathcal {H} $的冲突与中等长度的冲突消息而闻名，则可以推论$ \ mathcal {C} $的无数冲突。因此，安全性显然不比$ \ mathcal {H} $的抗碰撞性好（对于相同长度的消息）。我们可以假设$ k $是$ \ mathcal {H} $结果大小的一半，并希望安全性大约为269，或者SHA-1是257甚至是252、280、2128、2256个哈希轮，RIPEMD-160，SHA-256，SHA-512。
针对这些常见哈希中的每一个，对$ \ mathcal {C} $（优于以上）的已知攻击及其成本是什么？对于论证说，对$ \ mathcal {C} $的攻击会变成对$ \ mathcal {H} $的相似成本的攻击，或者相反的暗示？
更新：此答案类似的问题也很有趣，但我未能发现它确实回答了当前的问题。
更新2：我知道所考虑的构造比HMAC弱，尤其容易受到$ \ mathcal H $的碰撞；我说过这一点，因此，将密钥更广泛地毫无希望地将安全目标对准某些攻击，而不是散列大小的一半，是毫无意义的。我确切地问什么比在$ \ mathcal H $上找到冲突更好的密码分析攻击。仅通过利用具体$ \ mathcal H $的结构或/和舍入功能的弱点，才有进行此类攻击的空间。
#1 楼
这种结构的一个问题在最初的HMAC论文的第6节“ Bellare，Canetti和Krawczyk的“用于消息认证的键控散列函数”中进行了描述，他们指出在$ \ mathcal H $上找到了冲突，即两个输入$ x \ ne x'$使得$ \ mathcal H（x）= \ mathcal H（x'）$直接在$ \ mathcal C $上产生碰撞，使得$ \ mathcal C（k，x）= \ mathcal C（ k，x'）$而不考虑$ k $。 （从技术上讲，这仅在碰撞是内部冲突的情况下才有效，就任何后缀$ s $而言，$ \ mathcal H（x \ | s）= \ mathcal H（x'\ | s）$当然，如果假设$ \ mathcal H $具有抗碰撞性，则此问题与无关紧要。 （尽管应注意，即使对于完美的$ n $位哈希，生日攻击也只能通过大约$ 2 ^ {n / 2} $的评估找到冲突，然后可以使用该冲突来破坏$ \ mathcal C $表示任何$ k $。）但是，考虑到达到完全的抗碰撞性的难度似乎与要求哈希函数的大多数其他安全属性相比，具有抗碰撞攻击性（HMAC构造提供了这种抗性，只要其他它所依赖的安全属性不会受到损害）可笑。
评论
$ \ begingroup $
是；这就是我提到的“一般性攻击”。
$ \ endgroup $
–fgrieu♦
2012年5月26日20:06
$ \ begingroup $
我得出结论，没有比这种通用攻击更好的已知攻击了，请接受答案。
$ \ endgroup $
–fgrieu♦
16年4月13日在7:07
#2 楼
将$ H（m \ mathbin \ Vert k）$与哈希函数$ H $，消息$ m $和密钥$ k $一起使用是构建MAC算法的一种可能方法。它不一定是好东西。它取决于使用的哈希函数。即使是一个好的算法，也不能排除其他“更好”的算法（例如性能）的可能性。为说明潜在的安全问题，让我们定义哈希函数$ H $如SHA-256应用于位反转输入；也就是说，我们将哈希函数的输入作为位序列，反转位的顺序（第一个位变为最后一个，第二个位变为倒数第二个，依此类推）。这是一个人为的例子，但它应该表明我的观点。该函数$ H $（显然）具有与SHA-256一样的抗碰撞，原像和第二原像的能力，因此，从该角度来看，它是一个安全的加密哈希函数。但是，将$ H（m \ mathbin \ | k）$与该哈希函数结合使用会很困难，因为$ H（m \ mathbin \ | k）= \ textrm {SHA-256}（\ textrm {rev}（k） \ mathbin \ | \ textrm {rev}（m））$，适用所谓的长度扩展攻击。
因此，$ H（m \ mathbin \ | k）$是否是安全的MAC取决于散列函数$ H $的微妙属性，经典的抗碰撞和原像断言并未涵盖这些属性。 HMAC是通过两个嵌套函数哈希函数调用精确定义的，因此可以在Merkle-Damgård类型的哈希函数（例如SHA-256）的情况下证明其安全性；像$ H（m \ mathbin \ | k）$这样的简单构造不适合这种证明。因此，这就是HMAC存在的原因：因为我们可以说服自己，它比您的建议更安全。
关于性能，您必须考虑哈希函数不一定是最好的在镇上处理批量数据。在现代PC上，专用的MAC算法（例如Poly1305或GHASH（GCM的MAC部分））比SHA-256或SHA-512轻松（或超过）5倍。
#3 楼
您创建的MAC通常称为键控哈希函数。完成此操作的方式有两个问题。一个是先对消息然后对键进行哈希处理，但是最好先对键然后对消息进行哈希处理。
其原因是，如果有人发现您的邮件有冲突，那么他们最终将使用相同的MAC。最好在结构的最前面放置已知不同的数据，以最大程度地发挥作用。
另一个是长度扩展攻击。这只是上面的概括-您想减少两条不同长度的消息最终发生冲突的机会。
如果您假设哈希函数不受长度扩展攻击，则带密钥的哈希（在密钥的前面）与HMAC一样好。
Skein具有此属性，并且还结合了它基于可调整密码和调整携带的三角洲。那是Skein的一遍MAC，Skein论文中对此有一个描述以及安全性证明（请参见www.skein-hash.info）。
评论
$ \ begingroup $
长度扩展攻击适用于$ \ mathcal C（k，m）= \ mathcal H（k || m）$，而不是$ \ mathcal C（k，m）= \ mathcal H（m || k ）$。是的，我知道后者并不比哈希大小的一半更安全，这已在问题中提到。
$ \ endgroup $
–fgrieu♦
2012年5月29日20:18
$ \ begingroup $
我不愿意购买$ \ mathcal H $不受长度扩展攻击的支持，$ \ mathcal H（k || m）$与HMAC一样好；我的理解是，HMAC修改后的安全性论证的一部分依赖于在两端处理$ k $。
$ \ endgroup $
–fgrieu♦
2012年5月29日20:49
$ \ begingroup $
@fgrieu Skein使用类似于$ H（k || m）$作为MAC的方案，我相信本文包含了该模式的一些安全证明。您可以将其与HMAC的证明进行比较，并检查他们是否进行了其他假设。我认为Skein论文中的大多数证明都假设底层分组密码具有某些属性。
$ \ endgroup $
– CodesInChaos
2012年5月30日10:30
评论
“因此，将密钥的宽度超过哈希的一半大小是毫无意义的”，我对此表示反对。较大的密钥可以防止对该密钥进行多目标攻击。广义上讲，您可以-但只有使用不受长度扩展攻击的更现代算法...并且我认为最好在消息之前加上密钥，而不是追加。参见crypto.stackexchange.com/questions/17735/…和crypto.stackexchange.com/questions/35127/…
您的问题确实不是“我们为什么要使用MAC算法”？相反，它实际上是H（m || k）一个好的MAC算法
crypto.stackexchange.com/a/2717/991