升級到 PQCrypto 的成本
我們已經對使用什麼 PQCrypto 提出了建議： PDF（第 11 頁）
對稱加密 徹底分析的 256 位密鑰：
- AES-256
- 帶有 256 位密鑰的 Salsa20
對稱認證資訊論 MAC：
- GCM 使用 96 位隨機數和 128 位驗證器
- 聚1305
使用二進制 Goppa 碼的公鑰加密 McEliece：
- 長度 n = 6960，尺寸 k = 5413，t = 119 錯誤
公鑰簽名基於雜湊（最小假設）：
- 具有 CFRG 草案中指定的任何參數的 XMSS
- SPHINCS-256
升級到這些建議需要多少費用？
我們假設這些建議將經受住進一步的審查，並且升級軟體是免費的。在實踐中，它將作為無論如何都會發生的軟體升級的一部分發生。
什麼是額外的：
- 磁碟使用情況
- 記憶體使用情況
- CPU使用率
- 頻寬使用
對於普通使用者和普通網站？
由於使用者大多訪問與前一天相同的網站，我認為密鑰交換可能並不那麼可怕。如果 SSL 證書每隔幾個月才下載一次，那麼額外的頻寬將非常少。
如果您已經在使用 HTTPS，那麼使用 AES-256 或 Salsa20、Poly1305 或 GCM 身份驗證應該不會產生任何額外費用。如果你的伺服器有點現代，頻寬成本是每個發送的 HTTPS 數據包大約 16 個字節和幾百字節（最多）的 RAM，與伺服器上執行的實際業務邏輯相比，性能成本相當小。你不應該擔心這部分。
不對稱部分是有趣的部分。作為伺服器，您必須為每次握手生成 1 個 TLS 簽名（因此每個請求最多一個），並且SPHINCS-256 在 Intel Kaby Lake CPU 上花費 43M 週期，在 2GHz CPU 上約為 20ms。簽名為 41kB，這意味著每次握手的 RAM 成本可能約為 40kB，而頻寬成本也大致相同。現在，如果您傳遞 2MB 的 JavaScript，這將比您只使用一個非常簡單的靜態網站造成的傷害要小……我還沒有找到有關 XMSS 的數據，所以不會對此發表評論。
至於 McEliece，性能數據表明它需要大約2M 週期進行解密，這在 TLS 握手期間發生一次，因此在 2GHz CPU 上大約需要 1ms。但是，公鑰是 1.3MB，通常每次握手傳輸一次。實際密文只有 $ n $ 位，因此僅比可比較的 RSA 加密大一點。儘管現代 TLS 1.3 不再支持密鑰傳輸（即密鑰協議的公鑰加密），但您可能需要注意。
因此，我們總共得到大約 45M CPU 週期的成本和每次 TLS 握手大約 1.4MB 的成本，這在現代伺服器 CPU 上大約是 23ms。