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 個元素中。