題干與適用場景
公司有行動端、Web、裝置與第三方 API 用戶端，仍使用 RSA 或橢圓曲線。請設計一套遷移到後量子密碼的計畫，說明如何處理相容性、效能、金鑰輪換與回滾。
NIST 已發布 FIPS 203、204、205，分別規範 ML-KEM、ML-DSA 與 SLH-DSA。面試重點不是背演算法名稱，而是把長期機密性、用戶端生命週期與維運風險轉成分階段決策。IETF 的混合 TLS 草案仍屬草案，不能當成所有網路的既定相容承諾。
面試官考察點
面試官會看你能否盤點實際密碼資產，區分金鑰建立與數位簽章，解釋「先收集後解密」的風險，設計密碼敏捷性介面，並用相容率、失敗率與效能預算控制遷移。還要說明哪些結論需要安全、合規、供應商與產品團隊共同確認。
回答前需要釐清的問題
- 哪些資料需要保密十年或更久，哪些簽章必須長期驗證？
- 用戶端版本、韌體升級能力、離線週期與第三方依賴如何分布？
- 目前 RSA、ECDH、ECDSA 的呼叫點、憑證鏈、HSM 與備份在哪裡？
- 傳輸層、靜態資料、程式碼簽章與權杖簽章是否共用同一金鑰生命週期？
- 可接受的握手延遲、封包大小、CPU、記憶體與失敗率預算是多少？
- 能否保留舊演算法一段時間，誰有權批准降級與緊急回滾？
30 秒回答框架
「我先建立密碼資產清單與資料保密期限，再按暴露面、替換難度與用戶端可更新性排序。將金鑰建立與簽章分開設計，透過版本化演算法套件與能力探測支援經典、後量子或混合模式；預設拒絕靜默降級。先在可控服務與新用戶端灰度，記錄握手成功率、回應大小、CPU、回退與金鑰輪換指標。只有相容性、效能、稽核與回滾門檻都滿足，才擴大範圍，並保留舊金鑰的驗證窗口而不再產生新的舊格式。」
分步驟深入解答
第一步：盤點演算法與資料壽命
掃描 TLS、VPN、服務間 RPC、資料庫加密、備份、簽章、憑證、韌體與供應商 SDK 的呼叫點。為每個資產記錄演算法、金鑰長度、用途、擁有者、輪換方式、用戶端版本與資料保密期限。優先處理需要長期保密且今天已被收集的流量，再處理驗證壽命長的簽章。
第二步：建立風險分層與目標基線
用資產重要性、攻擊可行性、遷移窗口、不可更新用戶端比例與替換成本評分。基線應明確哪些新連線必須使用後量子或混合方案，哪些舊連線只能在有核准、短期限與監控的相容窗口內繼續。不要把「量子計算何時出現」當成唯一決策變數。
第三步：把密碼實作變成可替換能力
透過版本化的演算法套件、金鑰類型與憑證策略隔離業務程式碼與密碼函式庫。伺服器接受能力宣告，但不能讓用戶端任意選擇弱演算法；策略中心應能暫停某套件、切換供應商函式庫並記錄生效範圍。密文與簽章中繼資料要攜帶版本，避免未來無法識別歷史格式。
第四步：選擇金鑰建立與簽章路徑
ML-KEM 適合金鑰封裝，ML-DSA 與 SLH-DSA 用於簽章；它們的金鑰、憑證與效能特徵不同。對 TLS 等協定可評估經典加密與 ML-KEM 的混合握手，但先確認目標實作、草案狀態、閘道與終端支援。簽章遷移要單獨驗證憑證鏈長度、驗證成本與長期封存。
第五步：設計相容與回滾邊界
先讓新用戶端透過能力探測選擇新套件，舊用戶端進入明確的相容池。降級必須可觀測、限時、按租戶或裝置核准，不能因握手失敗就無限回到舊演算法。回滾只撤回新流量入口，不刪除仍需驗證的舊公鑰；每次回滾都記錄原因、範圍與再次啟用條件。
第六步：用灰度實驗驗證代價
在內部服務、可更新行動端與低風險租戶中測試連線成功率、握手延遲、訊息大小、CPU、記憶體、頻寬、憑證快取與 HSM 吞吐。分別壓測峰值、弱網、離線恢復與多地域。把後量子開銷與業務 SLO 對照，發現異常時按版本與用戶端類型回退，而不是關閉所有安全策略。
第七步：同步金鑰、供應商與稽核
定義新舊金鑰的產生、託管、輪換、撤銷、備份與銷毀窗口。驗證 HSM、雲端 KMS、憑證機構、代理與第三方 SDK 是否支援目標格式；將演算法套件變化寫入稽核事件。安全團隊負責策略，平台團隊負責實作，法務或合規團隊確認適用期限與證據留存。
第八步：設定發布門檻與長期退出
發布門檻至少包括相容成功率、效能預算、舊演算法流量占比、異常回退率、金鑰輪換成功率與稽核完整性。每個階段設定停止線與負責人；當舊格式流量低於閾值後，停止簽發新的舊憑證，再經過驗證窗口才撤銷接受能力。保留遷移記錄，方便下一次演算法替換。
設計取捨與邊界
混合模式與純後量子模式
混合模式可降低單一新演算法失誤的影響，但會增加握手大小、實作複雜度與協商測試量。純後量子模式更直接表達目標，卻可能排除無法升級的用戶端。選擇應由相容矩陣與風險門檻驅動，而不是由宣傳口號決定。
安全強度與效能預算
更大的金鑰、密文或簽章會影響 MTU、握手、快取與 HSM 吞吐。應按真實流量測量，並為行動網路、裝置 CPU 與峰值並發留出餘量。效能最佳化不能透過靜默降級換取。
回滾與舊金鑰保留
回滾入口與金鑰銷毀是兩件事。舊公鑰可能仍需驗證歷史簽章，因此不能上線回滾後立即刪除。可停止新簽發、限制新連線、保留唯讀驗證，並在證據足夠後再銷毀。
失敗演練與演進計畫
舊裝置無法升級
建立裝置版本清單，設定隔離閘道與明確到期日。驗證隔離不會把舊裝置的弱演算法擴散到新用戶端，並向擁有者提供升級或替換路徑。
握手變大導致連線失敗
在真實代理、負載平衡與行動網路中測試分片、MTU、逾時與重試。若新套件失敗，回到已核准的相容池並告警，不允許用戶端自行嘗試更多弱套件。
第三方只支援舊簽章
為第三方建立版本化介面與過渡憑證，限制舊簽章的有效期與權限。把升級承諾寫入供應商合約與驗收指標，不能把不可控依賴藏在「後續處理」。
常見誤區與追問
誤區一：把演算法替換當成一次設定發布
追問：你如何找到所有密碼呼叫點、備份與離線裝置？候選人應說明資產清單、依賴圖與責任人。
誤區二：把 FIPS 發布等同於用戶端全部相容
追問：目標函式庫、憑證機構、HSM、閘道與瀏覽器的支援證據在哪裡？候選人應區分標準完成與產品實作可用。
誤區三：失敗就靜默回退到 RSA
追問：降級由誰核准、持續多久、如何告警與退出？候選人應給出可稽核的相容窗口。
誤區四：只測平均延遲
追問：峰值並發、弱網、封包大小、CPU、記憶體與憑證快取如何驗證？候選人應描述分層壓測與停止線。
延伸追問與參考答案
為什麼要把金鑰建立與簽章分開遷移？
金鑰建立保護工作階段機密性，簽章保護身分與完整性；演算法、憑證鏈、金鑰尺寸與驗證壽命不同。拆開後可以按風險與用戶端能力分別灰度，避免一次替換阻塞全部業務。
如何證明系統具備密碼敏捷性？
展示演算法套件版本化、策略切換、金鑰中繼資料、供應商替換、相容矩陣、稽核事件與回滾演練。只能修改一個設定檔並不足以證明業務、憑證與裝置鏈路都可替換。
什麼時候可以停止接受舊演算法？
當新用戶端覆蓋率、連線成功率、效能與稽核門檻達標，舊流量已被定位且擁有者完成升級後，先停止新簽發，再經過唯讀驗證窗口，最後撤銷接受能力。每一步都應有回滾條件與負責人。