HMAC的内外层密钥哈希

内层把密钥混入消息处理，外层再用不同pad把内部摘要封住。攻击者拿到的是外层输出，不能像某些Merkle–Damgård裸前缀哈希那样，把暴露的链值继续扩展成合法新消息标签。

内外pad是构造规定的一部分，不是两把可随意选用的独立密钥；把它们设相同、删除一层或调整填充，都变成另一个需要重做分析的算法。现实应用应调用可信库，手写公式主要用于理解和标准向量核对。

RFC4231测试1使用20字节 0b 作为密钥、ASCII字符串 Hi There 作为消息。HMAC-SHA256完整32字节结果为

b0344c61d8db38535ca8afceaf0bf12b881dc200c9833da726e9376c2e32cff7。

可以逐层复算：先把20字节密钥补44个零；分别与64字节ipad、opad异或；内层哈希输入长为64+8=72字节；外层输入长为64+32=96字节。这里是传入哈希的长度，不含SHA-256内部自行添加的填充。

若密钥是100字节，先哈希得到32字节，再补32个零；不能直接截成64字节。HMAC的密钥归一化也意味着不同原始密钥可能得到同一 $K_0$，例如短密钥后添零在一定长度内不改变归一化结果。因此“密钥字节不同”不等于统计独立密钥，应用应采用规定的随机密钥生成与用途派生。

HMAC不隐藏消息，也不自动拒绝旧消息。收到一份旧的合法标签再验一次仍会通过，协议需要自己的接收状态。使用短标签时，理想 $t$ bit标签的单次盲猜成功率是 $2^{-t}$，多次在线尝试还要计查询预算；不能用摘要算法名掩盖实际只比较了4字节。

HMAC把既有MAC抽象落到一个可互操作的字节算法，但旧MAC页中的EUF-CMA、强新鲜性和PRF归约仍是安全接口的主定义。HMAC的内外层结构不能被当成任意组合协议的认证证明。

检查器通过Python标准库计算RFC4231已公布向量，再用同一HMAC实现HKDF。两个输出一致支持实现符合这些测试输入；它不测试底层机器的侧信道，也不证明所有消息长度或所有平台的实现都正确。

若底层哈希每块成本固定，消息m字节、原密钥k字节，计算成本为 $O(\lceil m/B\rceil +\lceil k/B\rceil +1)$ 次块处理；短密钥不需先哈希。流式实现除输入和输出外可用 $O(B+h)$ 工作空间，长消息不必全部驻留。固定密钥下可安全复用库规定的内外初始状态优化，但不能复用上一条消息的最终链值。