这些update方法使用给定的输入更新 HMAC 算法的内部状态。一个被调用的方法update几乎普遍地与某种final方法相结合(有时被调用doFinal或类似以避免与关键字 named 发生名称冲突final)。这个最终方法执行内部状态的最后更新并执行任何最终操作。
在 HMAC 的情况下,它对o_key_pad和散列i_key_pad,当然还有消息执行最终散列。该final方法也可以以不同的方式调用;例如,对于 HMAC,调用它digest来计算最终摘要,即 HMAC 计算的输出。
创建更新方法是为了允许使用多个更新流式传输大型消息。final 方法是必要的,因此算法知道已经到达消息的结尾并且可以执行最终操作。
签名生成和 HMAC 计算具有相当相同的目的;一个是使用对称密钥,另一个是非对称密钥对。但通常签名生成/验证与 HMAC 生成/验证几乎相同。
如果使用加密,则更新也可能返回密文或明文输出。如果确实如此,则取决于算法和算法实现返回什么以及何时返回。例如,如果您调用 CBC 模式,则至少需要缓冲一个明文/密文块,然后才能进行任何块加密/解密。然而,原则上计数器模式可以直接返回特定字节的密文;这是流密码的在线属性。然而,实现也可能决定缓冲明文/密文,直到一个完整的块可用。
在 NodeJS 的情况下,还有一个 CCM 模式的实现。update此模式对和都有特殊要求final。update可能只调用一次,并且final
必须精确调用一次。CCM 模式适用于无法使用流更新的数据包格式,因此多次更新会破坏 CCM(其中包括计算身份验证标签前面的消息大小)。最后,final需要调用来创建/验证身份验证标签。
笔记:
通常,初始的内部状态要么在创建期间设置,要么通过使用显式初始化方法设置。NodeJS 显然在创建对象期间选择了初始化。
哈希算法还需要缓冲明文,因为它们只能对明文块进行操作(准确地说,SHA-256 为 512 字节,SHA-512 为 1024 字节)。然而,这对散列函数的用户来说是透明的,因为它们不生成中间输出。HMAC 仅基于散列函数和一些 XOR'ing,当然具有相同的要求,因此需要缓冲。
有时update还需要该功能,因为并非所有消息都同时可用或在同一个数组中可用。例如,TLS 对所有发送/接收的握手消息进行身份验证,因此update在下一条消息可用时调用。
其他不处理大消息的算法通常不包括更新方法。例如 PBKDF2 不使用update,因为没有理由流式传输密码或盐;它们只是使用单个变量给出。