管道中的安全性
我是密碼學的新手，我正在嘗試設計一個安全的管道環境來快速傳輸消息。為了減少密鑰大小，我計劃使用 AES 會話密鑰（用於會話或 epoch）加密消息，並且在每個會話中，我計劃使用 DES 等輕量級密鑰加密每條消息（如果我錯了，請糾正我）。但是我面臨的一個基本問題是如何使這個通道在 DOS 攻擊下具有彈性？我是否需要刪除一些消息或為頻道中的所有消息提供時間線，之後它將燃燒，例如：生存時間？
我是密碼學新手，
是的，我們可以看到您如何使用術語。
我是密碼學的新手，我正在嘗試設計一個安全的管道環境來快速傳輸消息。
“管道”的另一個詞是“通道”，消息的傳輸也稱為“傳輸”。所以你需要一個安全通道來保證傳輸層的安全。TLS 顧名思義就是這樣。
為了減少密鑰大小，我計劃使用 AES 會話密鑰（用於會話或 epoch）加密消息，並且在每個會話中，我計劃使用 DES 等輕量級密鑰加密每條消息。
因此，根據本文，您正在使用 AES 和 DES 加密消息？DES 使用 56 位密鑰（儘管通常以 64 位/8 字節儲存，包括奇偶校驗位）。所以是的，密鑰確實是“輕量級的”，但密碼本身絕對不是。有點安全的三重 DES 比 AES 慢，這不是最輕量級的密碼；此外，它需要 168/192 位密鑰。
當“DES”這個詞被用於任何新協議或論文時，現代密碼學家會翻白眼。如評論中所述，現代輕量級（流）密碼通常更有意義。
但是我面臨的一個基本問題是如何使這個通道在 DOS 攻擊下具有彈性？
儘管您可以嘗試提前執行最少數量的操作——例如通過消息計數器驗證 MAC——抵禦 DOS 攻擊的彈性通常在較低級別執行；一旦您需要執行加密/解密，它很可能也是如此。
我是否需要刪除一些消息或為頻道中的所有消息提供時間線，之後它將燃燒，例如：生存時間？
您可以使用 TTL。但是，例如，如果您要轉發消息，TTL 似乎主要是有趣的 - 我們不知道您的協議是否旨在這樣做。