鉴于您使用SHA-3哈希（可抵抗长度扩展攻击），您是否仍需要按顺序执行该过程产生一个安全的MAC？
#1 楼
假设您使用SHA-3哈希（可以抵抗长度扩展攻击），那么您是否仍需要经历该过程才能生成安全的MAC？
否，您不需要这样做，但是您可以。
不用说我们仍然会使用一个键，该键是我们在消息之前或之后添加的，但是是的，对于MAC是否足够？
是的，您可以在消息前添加密钥，即使用$ H（K || M）$。
引用Keccak（SHA3）网站：
与SHA-1和SHA-2不同，Keccak没有长度扩展方面的弱点，因此没有需要HMAC嵌套结构。取而代之的是，可以通过简单地在消息之前添加密钥来执行MAC计算。 br />现在有了基于SHA-3或特别是SHAKE可扩展输出功能的KMAC（和其他构造）规范（pdf）。从“前置键到消息”的更改是键填充以及常量和输出长度的包含，所有这些操作都用于域分隔。
可以使用以下形式实现KMAC SHAKE128 / SHAKE256，但不使用其他SHA-3变体。
评论
$ \ begingroup $
我还想指出，将MAC与SHA-3一起使用实际上比使用HMAC更可取，因为HMAC实际上将不必要地使身份验证代码的计算时间加倍。
$ \ endgroup $
– Ninja_Coder
17年8月4日在7:57
$ \ begingroup $
Ninja_Coder，您有证据证明这项性能要求吗？听起来很合逻辑，但是单个SHA3仍然比单个SHA2慢很多（bench.cr.yp.to/results-hash.html#amd64-skylake）。
$ \ endgroup $
–Ruben De Smet
18年1月26日在18:22
#2 楼
指定KMAC的工作正在进行中。它基本上只是SHA-3，但是具有密钥的长度说明和一个特殊值，以指示这是KMAC而不是哈希。包含以前散列的数据，或者-更重要的是-密钥/消息对，其中$ H（K_1，M_1）= H（K_2，M_2）$，以防万一M_1 = K_2 | M_2 $。如果$ K_1 = A | X $，$ M_1 = B $和$ K_2 = A $，而$ M_2 = X | B $两者都将导致$ H（A | X | B）$。 $ | $运算符当然是连接的。评论
$ \ begingroup $
这个问题不是理论上的吗？只要您的密钥是128位以上的位并且是随机选择的，无论如何都不会有人以它开头的消息散列。 （或者，如果有人拥有，这与共享您的MAC密钥（这是256位密钥的参数）的人所获得的机会差不多。）还是关于更好的安全性证明？
$ \ endgroup $
–otus
16年6月8日在17:52
$ \ begingroup $
@otus我猜主要是后者。 OTOH只是给单个字节加上密钥长度（以字节为单位）作为前缀也不是什么大问题。对于像Keccak这样的高安全性结构，我可能会选择一个256位密钥。
$ \ endgroup $
–马腾·博德威斯♦
16年6月8日在21:18
$ \ begingroup $
基于此，它比我可以找到的其他KMAC东西更新，似乎该计划是完全域分离的，因此不能仅使用SHA-3来计算KMAC。 （假定某些SHA-3常量或参数将针对KMAC进行更改。）
$ \ endgroup $
–otus
16年6月9日在6:09
$ \ begingroup $
@otus是的，这是一般想法。它们只是SHA-3规范的2.1和6中的两位。这引起了我的注意；我不知道他们为什么只使用两个位？一个完整的字节会更有意义。我想我会叫这种烦恼。无论如何，您当然仍然可以将两位扩展为值11。有时我会忘记密码学家并不总是那么实用。
$ \ endgroup $
–马腾·博德威斯♦
16年6月9日在6:45
评论
使用密钥作为前缀而不是后缀。只要SHA-3保持不间断，作为后缀的密钥就很安全，但是一旦发现碰撞攻击，它就会掉落。如果您不关心性能成本，那么仍然使用HMAC也是一个不错的选择。这个问题非常类似于Skein可以用作格式为H（k || m）的安全MAC吗？
@CodesInChaos，该帖子似乎采用了Merkle–Damgård结构，而SHA-3 / Keccak使用了海绵结构。仍然适用吗？
这个问题可以说更接近了，但是并不是一个重复的问题（我投了赞成票），因为它询问HMAC-SHA3是否可证明是安全的，而不是是否存在较小的方案。查看专用的Keccak MAC功能（例如，作为其AE方案的一部分），包括Keyed Sponge功能。
@figlesquidge安全性是一个相对的概念。您在评论中链接到的问题，以及对该问题的公认答案，详细说明了HMAC-SHA3比在其内置MAC模式下在SHA3中使用时更安全的程度。