是否絕對需要使用公鑰來啟動加密會話？
我是一名使用 .NET 平台開發應用程序的軟體開發人員。此應用程序需要提供安全連接並加密客戶端和伺服器之間的所有數據。這是一個獨立的應用程序，不使用網路瀏覽器，並且將為絕大多數消息使用對稱密鑰以獲得最佳性能。會話預計會持續幾分鐘到 24 小時以上。在密碼學方面我有點初學者，但我做了一些研究。
從我所做的研究來看，目前的想法似乎是使用一對公鑰/私鑰來啟動會話。客戶端發送的第一條消息用公鑰加密，然後由伺服器用私鑰解密。在發送到伺服器的第一條消息中，還傳輸了一個隨機對稱會話密鑰，然後將其用於會話的其餘部分，然後在使用後丟棄。這一切似乎都很合理，但我確實有一些問題和擔憂：
- 如果將公鑰/私鑰用於初始消息，那麼是否應該為所有客戶端使用相同的公鑰/伺服器私鑰？或者，每個使用者都應該有一個單獨的公鑰/私鑰嗎？應用程序客戶端不需要維護用於解密來自伺服器的公鑰消息的私鑰，因為所有進一步的消息都將使用對稱加密。我擔心的是，如果只使用一個密鑰對並且有人確實設法找出了那個 2048 位私有密鑰，那麼該應用程序的所有使用者都會受到攻擊……
- 根據我所做的研究，似乎有些人建議應該使用不少於 2048 位的 RSA 密鑰。如果這個應用程序起飛，它很容易在 5 年內擁有 500,000 個使用者。生成公鑰/私鑰 2048 位密鑰對需要一些時間（如果您知道需要多少時間 - 請連同硬體一起告訴我），並且有 500,000 個使用者，將來可能會導致一些嚴重的時間延遲。想像一下需要重新生成所有 500,000 個密鑰對的場景。那需要多長時間？所以，我想知道是否有另一種啟動會話的方式同樣好，並且避免使用公鑰/私鑰對來啟動會話……
- 該應用程序將有一個與之關聯的網站，允許使用者使用使用者 ID 和密碼進行註冊。我正在考慮做的是應用密碼來生成初始對稱密鑰，該密鑰將用於加密發送到伺服器的第一條消息。在第一條消息之後，隨機會話密鑰仍將被傳輸和使用。為了辨識使用者，將在註冊時向客戶端安裝提供唯一的使用者令牌，該令牌將附加到第一個加密消息中，並且不會加密使用者令牌。一旦伺服器收到第一條消息，它就會查找令牌並獲取密碼。然後在伺服器上生成該密碼的對稱密鑰，與在客戶端上生成的方式完全相同。這 。NET 平台提供了一種使用 PasswordDeriveBytes 類從密碼生成密鑰的方法。因此，這種方法似乎會奏效，但我不是該主題的專家，並且希望聽到其他更有經驗並且能夠指出我可能遺漏的任何內容的人…
- 我還研究了對稱密碼。由於性能和安全性都是一個問題，我正在考慮使用 CAST-128 而不是 Rijndael，現在幾乎每個人都將其用作 AES。這是因為根據一些基準測試，CAST-128 在 Windows 系統上更快。此外，從安全的角度來看，與美國、其他政府和大多數公司正在使用的密碼相比，我更願意使用一種不太流行的密碼。打破 Rijndael 比僅由加拿大政府和 PGP 使用的 CAST-128 更感興趣。
我將解決你的最後一個子問題，關於 CAST-128。
我們在 PGP 中使用了它，因為那是 1997 年更好的選擇之一。它不再是 1997 年。它沒有任何問題，但是這些天你可以做得更好。
CAST 在當時甚至有點爭議，但我們喜歡它。它實際上是從一個框架設計的，並且是開發密碼框架的首批嘗試之一。但當時其他的選擇相對較少。3DES 曾經（並且現在）很慢，而且還有很多關於 DES 的殘餘憤怒。IDEA 已獲得專利並且許可不一致。Blowfish 也被認為很慢，但事實證明，如果您在任何大小的設備上使用 Blowfish（即攤銷慢鍵計劃時），Blowfish 的速度會非常快。
這些天來，您應該使用 AES，除非出於其他原因有充分的理由。你說的理由（美國政府）其實是錯誤的理由。不要基於政治做出加密決定。在任何體面的實現中，AES 應該比 CAST 更快。
但更重要的是，AES 有一個 16 字節的塊。應該避免使用具有 8 字節塊的那個時代的所有密碼，因為它們具有對數據長度相對較少的 GB 很重要的生日攻擊。（大約 50% 的機率 $ 2^{32} $ 密碼塊，這是 32 GB。）
我聽到你說，“但我不會加密那麼大的東西。” 你會的，相信我。即使你不這樣做，這也是不使用 AES 的錯誤理由。您需要 128 位塊。
如果你真的不想使用 AES，你應該使用 Twofish 或 Serpent。他們是 AES 和完全合理的功能的無 IP 決賽選手。如果你仍然想使用不是 AES 的東西，我推薦 Threefish。它的執行速度是軟體 AES 的兩倍，並且具有塊大小非常大的優勢。您可以通過Skein/Threefish 網站找到它的實現。我自己正在使用 Werner Dittmann 的實現。