UDP數據包的認證加密
我正在研究基於 UDP 的文件傳輸協議。處理擁塞控制、重新發送包和其他 UDP 挑戰 - 速度測試表明，當延遲/rtt 大於 100 毫秒時（例如在歐洲和美國之間），該協議傳輸大文件的速度比 HTTP 快 10 倍。
該協議將用於伺服器/客戶端架構 - 伺服器將向/從許多客戶端發送/接收數據。
伺服器執行 .NET - 客戶端將使用 .NET、Java (Android) 和 Swift (OS X、iOS) 編寫。
而且 - 現在是時候讓 UDP 協議安全了。
一些要求：
- 必須安全快速:)
- 必須在 .NET、OS X 和 Java 上受支持
- 必須支持某種 SessionID - 以便伺服器可以將不同的客戶端與另一個客戶端分開，並為每個客戶端使用適當的密鑰。
閱讀這篇文章，我同意 Otus 批准的答案：
- 不要推出自己的協議，而是使用 (D)TLS。
- 如果您必須使用自己的協議，請使用經過身份驗證的加密模式。
- 如果不能，至少使用標準加密和 MAC。
以下是我對這 3 個替代方案的看法：
DTLS 我對 DTLS 有點懷疑的原因是我無法在 C# 中找到任何好的/受信任的實現。根據 Inferno的說法， BouncyCastle是一個古老的加密貨幣和壞港口博物館。Eldos 有另一個實現，但我不確定質量 + 它有點貴。
Authenticated Encryption Mode AES-GCM 是一個很好的 AEAD 候選者，而且速度也很快。Inferno有一個 .NET 實現，似乎有很好的 Java 和 OS X /iOS 候選者（OpenSSL）。然而——我對讓所有這些庫正確地協同工作有點懷疑——只是一種直覺。SessionID 可以作為 AdditionalData (AE AD ) 包含在內。
標準加密和 MAC - 這是我目前的想法：
Get TLS1.2 Cert Client 通過 .NET HTTPS 呼叫檢索伺服器的 TLS1.2 證書。客戶端還通過此呼叫對伺服器進行了身份驗證。
**握手。**客戶端生成一個 KEY - 並使用伺服器的公鑰對其進行加密。客戶端向伺服器發送一個“握手”UDP 包，其中包含：
SessionID - 客戶端生成的 Guid。用於辨識所有後續通信的客戶端。（由於停車場問題，我不希望使用 IP/埠的組合來辨識客戶端）
(1) + (3) + KEY（通常稱為 MAC）的 SHA-256 雜湊
生成的密鑰 - 使用伺服器的公鑰加密的 AES-256。
伺服器和客戶端現在有一個共享的私鑰，他們都使用它來同步加密/解密他們發送/接收的消息——我猜這與 SSL/TLS 的工作方式非常相似。（使用伺服器的私鑰/公鑰進行非同步加密/解密會非常慢）
伺服器發送的每個後續 UDP 包將包含：
會話 ID - GUID。純文字。伺服器使用它來查找它的密鑰。
(1) + (3) + KEY 的 SHA-256 雜湊。這樣 - 明文 SessionID 已通過身份驗證。
使用 AES-256 加密的有效負載
優勢 - 正如我所看到的 - 是我使用標準化（且相對簡單）的建構塊，這些建構塊經過充分驗證並且易於在所有平台上實現/測試/調試。我還得到了一個經過身份驗證的 SessionID。
你覺得呢？你有沒有什麼想法？3. 是一個可行的選擇 - 還是我應該放棄這種方法？
您可以在此處使用 DTLS。C# 可以通過 P/Invoke 呼叫任何 C API。OpenSSL、BoringSSL、網路安全服務 (NSS) 和 mbedtls 都為 DTLS 提供了 C 介面。
除非存在現有綁定，否則您至少需要自己實現一些 P/Invokes，但這比編寫自己的加密協議要容易得多**。**
如果您可以開源這些綁定，那將是非常好的，以造福那些追隨您的腳步的人。
另外，請注意，在沒有硬體支持的情況下，AES-GCM 很難以一種不受記憶體定時側通道攻擊的方式實現——事實上，它非常棘手，以至於許多生產實現都沒有針對這種情況進行強化。攻擊。不受記憶體定時攻擊的實施提供次優性能。ChaCha20-Poly1305 是一種高效、安全且便攜的替代方案。它比純軟體 AES-GCM 快幾倍，同時不受許多側通道攻擊的影響。既然你提到了移動設備，你可能不會有對 AES 的硬體支持，所以 ChaCha20 更快更容易安全地實現。
對於來這裡的人來說，請查看QUIC。Chrome 自 2013 年以來就有它，還有其他幾個公共實現，MS 即將加入，標準化程序正在進行中：WG 文件，標準草案