為什麼不在 RSA 中使用隨機填充？

考慮以下場景：

發送者 S 向接收者 R 發送消息。他使用混合加密方案，RSA 作為密鑰封裝算法，AES-256-CTR（4 字節計數器）和 SHA256-HMAC。這些算法由接收者指定並且已經知道→接收者知道加密的密鑰長度： 32byte AES-key + 12byte AES-nonce + 64byte HMAC-key = 108byte

為什麼不用RSA(SECURE_RANDOM(404) || key-block)作填充方案？

1. 接收方已經知道長度，因此沒有理由指出它。
2. 如果 key-capsule 被更改，它將被檢測到，因為解密的密鑰將是錯誤的，並且 HMAC 驗證將失敗。
3. 它不應該受到 padding-oracle-attacks 的影響，因為應用程序無法區分正確的解密和缺陷填充（與標准後的 PKCSv1.5 和 OAEP 相比）。

可能有一個很好的理由不這樣做，但我沒有看到它。

能夠查看加密/解密是否失敗是一項重要功能。當然，填充預言是一個問題，但不執行操作的內在驗證的協議也是一個問題。

如果您有一個密鑰協商協議，那麼您需要某種方法來驗證對稱密鑰的解密是否成功。現在，您可以通過在由生成/解密密鑰計算的某個常量值上添加單獨的身份驗證標籤來做到這一點。然而，這會將這些資訊洩露給攻擊者。因此，您可能需要針對某些挑戰執行 MAC 計算，您還需要將其包含在消息中。您還可以使用解密的值作為種子創建一個額外的密鑰，並使用它來驗證結果，但同樣：需要額外的操作並且仍然有一個身份驗證標籤要發送。請注意，MAC 標籤也容易受到（基於時間的）預言機攻擊。

您真正不想要的是隱式驗證，即使用生成的密鑰並查看您是否在實際數據上遇到驗證錯誤。我正在使用執行此操作的協議，它會導致可怕的實現選擇。在協議的更新中，使用了第三個密鑰（用於 HMAC 握手）的顯式身份驗證。

所以目前有結果的內在驗證，在你的方案中沒有。也就是說，您的方案可能是安全的。RSA KEM更加安全，因此如果您喜歡您的方案，您可能應該選擇 RSA KEM 並在包含封裝密鑰的同一消息中發送身份驗證標籤。

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