SHA256 (RFC 4634) 中“Length_Low”和“Length_High”的含义？

Question

我今天在学习SHA2，到了我看不懂的代码的地方。

RFC 4634 （其中定义了 SHA2）在sha.h文件中定义了两个变量Length_Low和Length_High ：

例如，在sha224-256.c文件中，变量Length_Low在两个地方被主动更改。 这里：

和这里：

我了解 RFC 4634 和 SHA2 的原理。 但是，作为 C 的初学者，我只能理解论文中 99% 的代码。 我附上的图片属于这剩下的1%。

您能否解释一下， Length_Low和Length_High变量在 SHA2 的实现中起什么作用？ 它们在代码级别的含义是什么？

其次，后两个图像中发生了什么？ 我可以识别复合运算符和移位，但我对代码的难度感到不知所措——尤其是在第二张图片中，取消引用、递增、定义等发生在同一行代码中。

Answer 1

元：stackexchange，尤其是stackoverflow，政策是不发布“代码”的图像，广泛定义为包括配置文件和日志或错误消息等内容，因为它们在移动设备上很难阅读，视障者无法阅读人，不可剪切和粘贴，不可搜索。 加上你的，我认为你的 IDE 重新格式化和着色，在我看来非常难看。 幸运的是，所有的 RFC 都以文本形式发布，我可以很容易地替代它。

另外，顺便说一句：SHA-256 和 SHA-224（以及它们之前的 SHA-1 和 MD5）的输入块大小是 64个八位字节或 512 位，而不是 64 位，并且无论如何与长度字段无关。 长度字段确实是 64 位，并在代码中实现为高半和低半的两个 32 位变量。

static uint32_t addTemp;
#define SHA224_256AddLength(context, length)               \
  (addTemp = (context)->Length_Low, (context)->Corrupted = \
    (((context)->Length_Low += (length)) < addTemp) &&     \
    (++(context)->Length_High == 0) ? 1 : 0)

将一段输入数据的长度（实际上始终使用 8 表示完整的八位字节或 1-7 表示剩余位）添加到 2x32 位长度字段是相当棘手的代码。 首先它将传入的Length_Low保存在addTemp中，然后从内到外：

(context)->Length_Low += (length) // call this CODE1

将length的值添加到结构中的Length_Low字段； 因为这在 C 中使用无符号算术，如果结果（数学上）溢出，它会被环绕（取模 2 ³² ）。 因此，当且仅当发生溢出/环绕时，总和（ addTemp中的新值）小于Length_low中的原始值。 这是经过测试的，在这种情况下， Length_High字段会增加：

( CODE1 < addTemp) && (++(context)->Length_High == 0) // call this CODE2

如果在增加高半部分后为零，这意味着它也溢出/环绕，这意味着真正的消息长度太大而无法按照规范要求放入 64 位字段，因此这被认为是错误并存储在Corrupted字段中，稍后将对其进行测试以报告哈希操作失败：

(addTemp=..., (context)->Corrupted = CODE2 ? 1 : 0)

应该注意? 1: 0 ? 1: 0在技术上是不必要的； &&和|| C 中的运算符（以及像<和==这样的比较/相等运算符）已经定义为返回 1 表示真，返回 0 表示假（尽管if(x)和while(x)等测试接受任何非零值作为真）。 然而，有些人觉得写出来更清楚，而且这种动机在 RFC 中尤其强烈，该 RFC 发布给广泛的受众，包括那些（像你一样）对 C 知之甚少的人。

事实上，将其写成（非常小的）function 而不是宏可能会更好，这将允许使用更明显的语句而不是复杂的嵌套表达式，并且 2006 年任何体面的编译器（现在少得多）都会inline 和 fold 以生成与宏相同的代码。 但这个世界并不完美。

相比之下，您的第三块非常简单。 它只采用 2x32 位长度字段并将其作为 8 个 8 位单元的大端序列存储在当前Message_Block的最后 8 个元素中。