在存在 HMAC 的情況下是否有必要（長度）填充固定長度的一次填充？
想像一個協議，其中所有一次性填充消息都是固定長度的。而且它們只是文字的，就像真相/推文一樣。因此，一條短消息將用空格（ASCII 32）填充到協議的固定長度，然後傳輸。它還將附加一個格式正確的 RFC 2104 HMAC，該 HMAC 本身使用多個一次性填充材料進行加密。
是否有必要在協議中的某處合併原始純文字的長度？
我覺得這是固定長度消息是否真的需要 HMAC 構造的副本？，但是這個問題有兩個很長的答案，我正在努力解析。將不勝感激這些的簡化或對此的回答。
是否有必要在協議中的某處合併原始純文字的長度？
不，只要消息的最後部分不能與使用的填充混淆，就可以確定性地取消填充消息。在您的情況下，如果您的消息不能以空格結尾，那麼您可以去掉空格。但是，如果它確實如此，那麼最後的空間顯然是。
我覺得這是固定長度消息是否真的需要 HMAC 構造的副本？
不，這是一個不同的問題。原因是它談論 HMAC 本身是必要的，而不是填充。
HMAC 是使用雜湊函式建構的，該函式已經在內部填充，假設它具有用於消息輸入的特定塊大小。對於 SHA-2，這意味著使用位填充來填充消息，留下一些字節來指示消息大小（以位為單位）。
HMAC 本身在散列中已經有一個長度指示符。但即使沒有它：在消息中添加任何數據都會立即更改身份驗證標籤，因此攻擊者不可能在沒有通知的情況下添加數據。為了安全起見，我還將填充包含在雜湊計算中，如果只是為了禁止長度資訊從未填充中洩漏。但最終，為了 HMAC 的安全，明文消息的填充是不需要的；它已經在內部這樣做了。
我將填充/取消填充與任何加密算法分開，因為您只想在 HMAC 驗證發生*後驗證填充。*即使這樣，您也應該真正注意任何操作，以免通過側通道洩漏有關消息大小的資訊。
您似乎在談論的是隱藏消息大小所需的填充。這不同於塊密碼或散列函式的填充。問題在於填充方案必須正確允許任何大小的輸入消息。這也可能意味著填充可能超過例如 PKCS#7 兼容填充所允許的 255 個字節。
從這個意義上說，如果填充大於 8 個字節，最好包含一個長度。在這種情況下，您可以設置一個位並假設其他 63 位由消息或填充長度組成。換句話說：長度指示器可能比某些填充方案更有效。OTOH，位填充也可以正常工作，但您可能需要查看所有填充字節以找到第一個未設置為全零 / 0x80 的填充字節。