關於 RFC 5246 的 padding 範例的正確性

PKCS#7 填充在rfc5652#section-6.3中定義

一些內容加密算法假設輸入長度是 k 個八位字節的倍數，其中 k 大於 1。對於此類算法，輸入應在尾端填充 k-(lth mod k) 個八位字節，所有字節的值均為 k-(lth mod k)，其中 lth 是輸入的長度。換句話說，輸入在尾端用以下字元串之一填充：

               01 -- if lth mod k = k-1
            02 02 -- if lth mod k = k-2
                 .
                 .
                 .
       k k ... k k -- if lth mod k = 0

正如我們所看到的，填充字節可以包含一系列01,02,...,或，16對於 16 字節大小的分組密碼。在讀的時候

• Merget 等人的2019 年TLS 填充 Oracle 漏洞的可擴展掃描和自動分類。

我已經看到他們舉了一個例子：

第二個塊包含剩餘的 9 個 HMAC 字節和7填充字節0x06，參見圖 1。注意加密器也可以選擇更長的填充並附加 23、39、…或 247 個填充字節（同時相應地設置填充字節的值）。

這不是 PKCS#7 填充。因此，我查看了 TLS 1.2 的RFC 5246並看到了幾乎相同的模式；

如果填充長度是必要的最小值 6，則填充將為 6 個字節，每個字節包含值 6。因此，在塊加密之前 GenericBlockCipher 的最後 8 個八位字節將為 xx 06 06 06 06 06 06 06，其中 xx 是MAC 的最後一個八位字節。

為了與 PKCS#7 填充兼容，以上內容應該是（看不到勘誤表）

如果填充長度是必要的最小值 7，則填充將為 7 個字節，每個字節包含值 7。因此，塊加密之前 GenericBlockCipher 的最後 8 個八位字節將為 xx 07 07 07 07 07 07 07，其中 xx 是MAC 的最後一個八位字節。

這篇文章也有一個錯誤。

據我所知，這兩個資源是不正確的。關於 PKCS#7 填充規則的不同設計/用法，我是否遺漏了什麼？

SSLv3 到 TLS 1.2 中用於 CBC 密碼套件的填充不是 PKCS#5/PKCS#7 填充。這是 SSL/TLS 中使用的填充，我在其他任何地方都沒有見過。

TLS 1.0、TLS 1.1和TLS 1.2中的填充可以是 1 到 256 個字節，因此它可以填充多個塊。在前身協議SSL 3.0中，它必須恰好完成一個塊。在所有版本中，最後一個字節必須是填充的長度，不包括最後一個字節。前面的字節可以採用 SSL 3.0 中的任何值，並且必須是 TLS 1.0 到 1.2 中的填充長度。對於一個分組密碼 $ B $ -字節塊：

如您所見，PKCS#7 用總填充長度填充填充，而 TLS 1.0–1.2 用總填充長度減一填充填充。這個看似奇怪的選擇的原因是它是對 SSL 3.0 填充的改編，其中最後一個字節是一個長度字節，不包括 SSL 規範所謂的“填充”，而“填充”本身可以有任意內容。

您從 RFC 5246 和 Merget 等人引用的範例。是正確的。如果添加 7 個字節使明文成為塊大小的倍數，則06 06 06 06 06 06 06可能是 TLS 填充（如16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16等）。

引用自：https://crypto.stackexchange.com/questions/98917