經典與量子安全算法和協議/應用方法
在後量子密碼學 (PQC) 世界中，正在為 X509 V3 證書探索各種提議。
目前，這些包括僅擁有一個經典證書和 PQ 證書，擁有一個使用 X509 擴展的經典證書和 PQ 混合證書，或者根據需要將盡可能多的簽名連接到一個 blob 中的複合證書。如果我理解正確，前兩種方法是 or 函式，也就是說，您只使用經典或後量子簽名。複合方法可以使用所有簽名，因此使用者必須驗證 blob 中使用的所有簽名。
這種理解對嗎？
我的問題是當你到達協議級別時。加密敏捷性被定義為安全系統能夠在算法、加密原語和其他加密機制之間快速切換而係統基礎設施的其餘部分不會受到這些變化的顯著影響的能力。
例如，行業如何考慮 TLS？是否有經典 TLS 和 PQC TLS？該協議是否只有兩種變體，似乎違反了加密敏捷性？如果有兩個，在實際實例化中需要在它們之間切換什麼？
另一種方法是使用混合 TLS，允許在協商中選擇經典或 PQC 算法。但是，標準機構需要多少年才能創建這樣的變體，因為這大大增加了複雜性，但也許這就是重點。請注意，我知道 Open Quantum Safe ( https://openquantumsafe.org/ ) 項目，但它們似乎都只創建了 PQ 變體。此外，在某些時候，您會淘汰經典算法，只支持 PQ 算法。這樣的轉變怎麼會發生？
關於 SSH、OpenSSL、gnu utils 和任何其他使用經典與量子安全算法的協議或應用程序，可以提出相同類型的問題。
這些事情是否還沒有解決，協議和應用程序開發人員需要數年時間才能召開工作組會議來決定如何在技術、後勤等方面完成這些工作？
在後量子密碼學 (PQC) 世界中，正在為 X509 V3 證書探索各種提議。
這種理解對嗎？
在我看來，基本上有兩種方法可以同時擁有經典和後量子證書：
- 擁有一個包含經典和後量子簽名和公鑰的“混合”（或複合或任何您喜歡的術語）證書。有幾種方法提出瞭如何做到這一點，它們有技術差異，但在這個高層次上並不重要。至於 AND/OR 爭議，我的觀點是：你總是檢查所有你知道如何檢查的簽名，如果有任何失敗（即 AND）就拒絕它——唯一出現的問題是你是否遇到了公眾您不了解其類型的密鑰…
- 或者，我們可以有兩個單獨的證書，一個是純經典的，一個是純後量子的；我們將使用證書修改協議以請求兩個證書，並使用兩個公鑰。這樣做的好處是後量子證書可能要長得多；我們不會為尚不支持後量子的人增加費用。
對於這兩種選擇中的哪一種更有意義，我還沒有看到任何共識。如果證書的不同用途可能採用不同的方法，我不會感到驚訝。
我的問題是當你到達協議級別時。加密敏捷性被定義為安全系統能夠在算法、加密原語和其他加密機制之間快速切換而係統基礎設施的其餘部分不會受到這些變化的顯著影響的能力。
例如，行業如何考慮 TLS？
我將假設這部分討論的是隱私方面，而不是身份驗證。
至於 TLS 1.3（目前似乎沒有理由修改 TLS 的早期版本），基本上已經解決了：我們將添加額外的“命名組”
$$ 1 $$，這是使用的密鑰交換算法。除了現有的（例如 X25519），我們將添加一個名為“NTRU”（將列出 NTRU 參數集）以及“X25519+NTRU”。後者要做的是並行實現 X25519 和 NTRU；密鑰共享將是 X25519 和 NTRU 密鑰共享連接，共享密鑰是 X25519 和 NTRU 密鑰共享連接（TLS 1.3 具有強大的 KDF，因此連接效果很好）。這在IETF 草案中有詳細說明 這使升級路徑變得容易；客戶將提出名稱組 X25519+NTRU 和 X25519；理解 postquantum 的伺服器會接受第一個；不能的伺服器會退回到第二個。然後，當需要放棄經典時，客戶將開始（僅）提出 NTRU；相同的升級路徑也適用於那裡。
我相信 OpenSSH 正在走類似的道路（僅使用 NTRUprime）；但是我沒有調查細節來確定。
$$ 1 $$：“命名組”現在用詞不當，因為後量子算法不基於組……