CMS 標準中的“消息摘要的初始輸入”是什麼意思
我真的很反對CMS標準中的摘要計算解釋。
讓我們考慮
signedAttrs存在 的情況。第一段說
消息摘要計算過程的初始輸入是被簽名的封裝內容的“值”。
對我來說，這意味著無論要簽署什麼摘要值，都以某種方式“開始”作為消息的摘要。
第二段說：
當。。。的時候
$$ signedAttrs $$欄位存在，但是，結果是 包含在 signedAttrs 欄位中的 SignedAttrs
值的完整 DER 編碼的消息摘要。
對我來說，這聽起來確實像是結果完全來自
signedAttrs價值，但第一段似乎是矛盾的，因為它說無論如何，摘要必須從封裝的內容開始。然後第二段確實提到內容雜湊將被間接包含，因為它必須存在，但對我來說，這仍然不能否定第一段中的暗示。PS 基於 OpenSSL 實現，我認為“正確”的行為只是 hashing
signedAttrs。
考慮這兩種情況。
**沒有signedAttrs：**首先我們對內容進行雜湊處理，然後我們對該雜湊進行簽名。我們要做的第一件事是對內容進行雜湊處理。
使用signedAttrs：首先我們對內容進行雜湊處理，稱之為hash1；然後我們構造signedAttrs，它在message-digest屬性中*包含hash1；*然後我們散列signedAttrs，稱之為hash2；然後我們簽署 hash2。在數字簽名操作中只使用了 hash2，但是要計算 hash2，我們必須事先有 signedAtttrs 的值，而要獲得 signedAttrs 的值，我們必須事先有 hash1，這是內容的雜湊，所以我們要做的第一件事是散列內容。
無論哪種方式，我們做的第一件事就是散列在輸入時使用內容的內容。因為這是我們做的第一件事，**所以最初的輸入就是內容。**特別是八位字節的值，而不是標籤和長度，這是該段落中指定的實際點。