MODULE m6 · 8.0 HOURS

效能評估與標竿測試

已完成 0%

LEARNING OBJECTIVES

本模組目標

  1. 理解後量子密碼演算法 (ML-KEM) 的效能評估指標 (時間、記憶體、處理量)。
  2. 分析 KEM 運算在 TLS 1.3 交握過程中對效能的影響。
  3. 利用 Liboqs 與 oqs-provider 框架標竿測試混合密碼模式的效能。

效能評估與標竿測試

遷移至後量子密碼 (PQC) 不僅僅是更換演算法，更是與現有網路協定 (如 TLS 1.3) 的效能直接相關的問題。特別是 KEM (Key Encapsulation Mechanism) 運算會直接影響交握的延遲 (latency) 與伺服器每秒連線處理量 (handshakes per second) [S2]。

效能指標

  1. 運算時間 (Computation Time): 金鑰產生 (KeyGen)、封裝 (Encaps)、解封 (Decaps) 各自消耗的 CPU 週期或時間 (ms)。
  2. 資料大小: 公開金鑰與封裝後文字 (ciphertext) 的大小。這決定了網路頻寬消耗與發生分段的可能性。
  3. 處理量 (Throughput): 每秒可處理的交握次數。優化實作 (例如利用 AVX-512) 可提升多項式乘法與模組化運算速度，大幅改善處理量 [S2]。

混合模式

轉型期建議採取同時使用傳統演算法 (ECDH) 與 PQC (ML-KEM) 的混合方法。這是為了在防範 PQC 潛在漏洞的同時，獲取 PQC 的安全優勢。由於混合模式運算複雜度增加，必須嚴密評估效能下降情況 [S2]。

WORKED EXAMPLES

講解範例

  1. 範例 1：利用 Liboqs 進行單一 KEM 運算標竿測試 透過 Python 腳本，利用 `timeit` 模組測量 `ML-KEM-768` 的 `keypair`、`encaps`、`decaps` 運作時間並儲存為 CSV 的方法。
  2. 範例 2：混合 TLS 1.3 交握處理量測量 在已套用 oqs-provider 的本地伺服器/用戶端環境中，使用 `s_client` 與 `s_server` 測量 100 次連線所需的總時間，以分析出計算每秒交握數 (TPS) 的程序。

LAB PROTOCOL

PQC 效能標竿測試實作

  1. 1

    在隔離的開發環境內安裝 liboqs 與 oqs-provider 並確認環境設定。

  2. 2

    撰寫標竿測試用 Python 腳本，測量 ML-KEM 演算法的運算時間。

  3. 3

    執行 Wireshark 擷取 TLS 交握封包，分析混合模式下的資料大小變化。

  4. 4

    基於測量資料，將運算時間與處理量指標繪製成圖表。

安全檢查
  • 實驗僅在本地隔離環境內執行，絕對不使用實際營運環境的憑證或金鑰。
  • 由於標竿測試過程中可能產生高 CPU 負載，請監控系統資源。
  • 注意避免將實際秘密值或金鑰資料包含在擷取檔案中。

實驗繳交成果

  • 運算效能測量腳本 (.py)
  • 測量結果 CSV 資料
  • 各演算法效能比較分析報告 (.md 或 .ipynb)

ASSIGNMENT

基於密碼敏捷性的效能評估報告

繳交成果

評分標準

  • 標竿測試資料是否在可重現且獨立的環境中測量？
  • 是否準確分析效能下降的技術原因 (金鑰大小、運算複雜度)？
  • 是否平衡討論了混合模式的優點與成本？

KNOWLEDGE CHECK

理解檢查

1TLS 1.3 交握效能中，最關鍵的 PQC 演算法相關要素是什麼？
2效能評估時使用混合模式的主要原因？

FIELD CHECK

完成標準

  • 完成標竿測試腳本執行與結果資料確保
  • 提交效能評估報告並通過
  • 完成 TLS 混合模式效能分析

MODULE SOURCES

本模組參考資料

  1. Faster Post-Quantum TLS 1.3 Based on ML-KEM: Implementation ...arxiv.org · paper