當加密消息是唯一的時使用ECB作為RSA加密模式？
據我了解，除非您對始終唯一且僅加密一次的單個數據塊進行加密，否則不應將 ECB 用作加密模式。
我有一組由整數表示的 id，我使用 RSA/ECB/PKCS1PADDING 使用相同的公鑰加密和傳輸（單獨）。有時，相同的 id 會被多次加密和傳輸，但據我所知，密文永遠不會相同。
誰能告訴我這怎麼可能？據我了解，這不是使用 ECB 的可接受方案，但為什麼即使密鑰和明文消息相同，加密消息也不相同？
"RSA/ECB/PKCS1Padding"正如您已經發現的那樣，Java 算法字元串沒有實現 ECB；它只加密/解密單個塊。Bouncy Castle 加密安全提供程序有一個更好命名的算法字元串 ，"RSA/None/PKCS1Padding"它更好地表明沒有使用任何操作模式。很可能"/ECB"只是為了模擬分組密碼的密碼字元串而包含在內。因此，您必須"RSA/ECB/PKCS1Padding"多次呼叫密碼才能實現 ECB。
"PKCS1Padding"表示帶有 PKCS#1 v1.5 填充的 RSA 用於加密。這個填充是不確定的——即它使用一個隨機數生成器。這就解釋了為什麼每個密文塊都會不同。為了使 RSA 安全，需要使用安全填充方案。如果使用 PKCS#1 v1.5 填充，那麼每個純文字塊都會有很大的（11 字節）成本。填充由至少八個字節的正隨機值組成，這解釋了為什麼即使相同的明文塊被加密，密文總是不同的。如果您在 ECB 模式下使用 RSA，那麼您最終會失去每個塊的填充成本。這意味著密文將明顯大於明文。
此外，RSA 操作需要大量 CPU 資源。RSA 加密/解密操作基於極大數的模冪運算。因此，對許多塊使用 RSA 操作將佔用大量 CPU 時間。對於解密尤其如此；加密的優點是公共指數通常相對較小。但即使是 RSA 加密也將比任何對稱密碼更耗費 CPU。
要加密較大的消息，您應該使用混合密碼系統，其中非對稱 (RSA) 加密與快速、高效的對稱密碼（如 AES）配對。在您加密大量數字的情況下，最好將它們聚合在一個結構中，使用 AES 加密該結構，然後使用您的 RSA 公鑰加密 AES 密鑰。
筆記：
- OAEP比 PKCS#1 填充更安全。如果選擇 OAEP，那麼填充成本會更大，使 ECB 效率更低；
- 也可以使用 RSA-KEM 或任何其他技術來建立對稱密鑰——然而這些技術目前還沒有出現在 Java JCA 庫中；
- 對於分組密碼，ECB 對明文中的每個分組執行分組密碼操作。在大多數情況下，這並不安全，與使用的填充無關。但是，它可用作較低級別的操作，例如對稱密鑰的密鑰包裝；
- 您可以使用容器格式，例如加密消息語法 (CMS)或Pretty Good Privacy (PGP) ，而不是設計自己的協議；兩種格式都已經實現了混合密碼系統；
- 通常不建議僅僅為了支持更大的消息而增加密鑰大小：這將需要在加密和解密期間大量增加 CPU 時間，僅與生成更大的 RSA 密鑰對所需的時間相比相形見絀；
- 您可能希望在加密之前對消息進行簽名以提高安全性（有時在之後簽名更有意義，這取決於案例）；
- 為 PKCS#1 v1.5 填充使用所有可能的字節有一個缺點：隨機填充只有 ~64 位，因此由於生日限制，可能會與較早的填充發生衝突 - 最好使用成本19 個字節而不是 11 個字節，並且有大約 128 位的填充。
在不知道您正在使用的確切實現的情況下，從算法名稱中，我認為您正在為對稱密碼生成一個隨機密鑰並使用 RSA 密鑰對其進行加密。這樣你的密文將是獨一無二的。
我建議使用提供完整性保護的密碼模式，例如AES-GCM或Poly1305-AES。如果在開發後期您的消息變得比單個塊長，或者您開始重新使用對稱密鑰，ECB 可能會很危險。
您還應該防禦重放攻擊。如果有人截獲並重新傳輸有效身份證件，會有什麼後果？
您是否考慮過使用現有協議，例如通過 SSH 或 TLS 建立隧道？如有必要，您可以使用密鑰固定並選擇一個好的密碼套件。