2026 年 HQC 已該接入生產系統嗎？

根據 NIST 的選擇公告，HQC 是 NIST 選入標準化的第五種後量子加密演算法；這不代表正式標準已發布。對 HQC 生產部署，建議是：先做隔離評估與互通測試，不要直接取代現有生產方案；本週先確認密碼庫來源、版本及回退路徑，再追蹤 NIST 狀態頁。

正在評估後量子密鑰建立的安全架構師，可以用本文區分標準進度與上線決策。
負責密碼庫選型的工程師，可以據此安排介面、互通和失敗回退驗證。
制定遷移路線的技術負責人，可以把試點、依賴項與複核條件記錄在同一份計畫中。

先分清現況：標準化選擇不等於正式標準

截至 2026 年 10 月 6 日，NIST 官方資料確認 HQC 已被選入標準化，但尚未發布 HQC 正式 FIPS 標準。請以 NIST 後量子密碼標準化狀態頁及 NIST IR 8545核對進度；不要把「選定進入標準化」改寫成「已標準化」或「已獲准投入生產」。

HQC 現在是正式標準嗎？
不是。現有官方狀態確認的是標準化選擇，不是已發布的正式標準。這個差別會影響規格穩定性、合規審查、密碼庫相容性和供應鏈安排。標準尚未定稿時，測試結果應標記為評估資料，不能當成正式標準符合性證明。

「第五種」也是有用的定位資訊，不是採用優先級。NIST 選入 HQC 進行標準化，並不表示每個機構都應把它排在現有算法之前。評估時至少要分開記錄四件事：標準化狀態、規格是否定稿、實作是否可用、組織是否批准部署。

現階段：把 HQC 放進評估清單，而非替換清單

你可以選擇與密鑰封裝、憑證流程或安全通道建立相關的測試環境，評估 HQC 對既有 API 和協定流程的影響。先確認所用實作的來源、版本、建置選項及支援狀態；如果資訊不完整，就不要把它列為可供生產呼叫的依賴。

正式標準發布前可以測試 HQC 嗎？
可以，但測試範圍要與生產環境分開，並清楚標示規格版本及實作來源。你可以測試呼叫介面、訊息編碼、錯誤處理和系統整合；測試通過只表示特定環境下的整合結果，不代表正式標準相容、合規或適合承載生產流量。

與其把所有測試機會都集中在演算法本身，不如先做以下對照：

• 標準狀態：HQ​​C 是待完成標準化工作的選項；ML-KEM 已有正式標準 FIPS 203。兩者不能被當成相同部署狀態。FIPS 203列出 ML-KEM 的標準要求。
• 測試目的：HQC 可用於隔離環境的介面與互通評估；ML-KEM 可依正式規格和組織要求進行標準化部署評估。
• 當前決策：如果業務需要現階段可依據的正式規格，先按已發布標準及內部政策評估；若希望預先掌握 HQC 的整合影響，將它列為試點，而非直接替換項目。
• 部署評分：對 HQC 的生產準備度目前應評為「待複核」，而非「可上線」。這是依標準狀態作出的決策標記，不是性能或安全性評分。

HQC 和 ML-KEM 有什麼區別？
就部署決策而言，關鍵差別是標準狀態和規格依據。NIST 將 ML-KEM 定為 FIPS 203；HQC 則仍處於標準化進程中。演算法設計路線也不同：NIST 的選擇公告將 HQC 描述為基於錯誤更正碼的方案，而 ML-KEM 規格屬於格基密鑰封裝機制。這些差異不應被簡化成「哪一個一定更快」或「哪一個必定更安全」；此類判斷必須有相同環境下的實測及明確威脅模型。

參數差異也會影響封包與協定設計，但不能拿一種算法的資料推估另一種算法。以 FIPS 203 的 ML-KEM-768 為例，公鑰長度為 1,184 位元組、密文長度為 1,088 位元組；這些是 ML-KEM 規格值，不是 HQC 參數，也不是效能數據。若你要評估訊息大小、封包限制或頻寬影響，應依正式規格和實際實作分別測量。

注意：NIST 選定 HQC 進入標準化，不等於已確認特定密碼庫支援，更不等於你的協定、產品或法規環境已具備部署條件。

標準發布前：先驗證端到端互通與失敗回退

不要只確認程式能呼叫某個函式。密鑰建立通常穿過應用程式、密碼庫、協定協商、金鑰保存和更新流程；單點測試不能代表整條路徑可用。NIST 的 SP 800-227 密鑰封裝機制建議可作為檢視 KEM 使用與金鑰管理流程的參考。若要設計遷移場景，可再核對 NIST NCCoE 後量子密碼遷移 FAQ所整理的遷移問題。

先逐項執行這份清單：

• [ ] 記錄測試程式、密碼庫及相依元件的來源、版本、建置方式與設定；將測試環境和生產環境的識別資訊分開保存。
• [ ] 驗證應用程式到密碼庫、協定協商到金鑰使用的端到端流程，並記錄使用的規格或實作版本。
• [ ] 在可控環境中驗證跨實作互通；若沒有第二個可核實的實作，明確記錄此項尚未驗證，不要寫成「互通通過」。
• [ ] 模擬協商失敗、對端不支援、參數不符及密鑰建立中斷，確認回退行為有明確限制並留下可追查紀錄。
• [ ] 核對金鑰產生、傳遞、保存、更新和銷毀流程；確認測試用金鑰不會混入生產憑證或長期金鑰管理流程。
• [ ] 記錄延遲、訊息尺寸和資源使用的測量方式、硬體環境與負載條件。沒有可重現的測量記錄，就不要對外宣稱效能優勢。
• [ ] 指定負責人、複核日期或觸發條件，並保存測試結果及回退決策。

如果你正在整理測試環境交付流程，可以參考 VPSSpark 說明中心，把環境準備、存取權限與測試紀錄分開管理。遠端測試另須把網路連線品質與演算法互通分開觀察；若工程師需在外出時使用行動網路，可參考 eSIM 方案資訊。行動網路可用性不構成 HQC 支援或相容性的證據。

正式標準發布後：重新審查，不要自動擴大部署

NIST 發布正式標準或更新標準化狀態時，先重新核對最終文本，再決定是否進入下一階段。NIST 的 IR 8547 初步公開草案可供追蹤後量子密碼遷移規劃相關內容；草案不能取代最終標準或組織的合規審查。若需要對齊術語，可參照 RFC 9794對後量子密碼相關術語的定義。

複核時依次確認：

• 最終標準文本及生效狀態是否已由官方發布；記錄文件版本，不要沿用草案或測試版本的結論。
• 密碼庫是否明確支援最終規格，版本、建置選項與供應來源是否符合組織的審查要求。
• 對端、協定及其他依賴方是否已有相應計畫；只要關鍵依賴仍未確認，就保留隔離試點。
• 先前的互通、回退與金鑰生命週期測試是否仍對應最終規格；不一致時重新測試。
• 合規、風險及營運負責人是否核准擴大範圍；任何一項未完成，都不應因標準發布而自動切換。

企業何時應把 HQC 納入遷移計畫？
現在就可以把它列入「待評估算法」，指定負責人、依賴項與複核觸發條件；不要把它與已定稿算法放在同一個部署狀態欄。等正式標準發布後，再按最終文本、密碼庫支援、依賴方進度和內部合規要求決定是否擴大部署。標準發布是重新評估的觸發點，不是全系統立即切換的指令。

把驗證環境和生產決策分開管理

你可以在隔離的開發環境中重現建置、介面呼叫和錯誤處理流程，但環境能執行程式，不代表其中的 HQC 實作符合最終標準。此文沒有可核實的 VPSSpark HQC 專用配置或復現紀錄，因此不對特定環境、性能或相容性作出聲明。

如果團隊目前依賴共用工作站或一般雲端開發環境，限制可能在於環境難以隔離、測試版本不易固定，以及平台相依的建置流程需要額外核對。Mac 也不是 HQC 安全性或標準符合性的證明；只有當你需要驗證 macOS 開發、建置或平台相依整合時，租用 VPSSpark Mac 環境才可能比臨時挪用共用設備更適合做短期、可重現的開發測試。若工作負載長期且穩定，或必須使用特定實體介面，自購設備或現有專用環境通常更值得評估。下一步可先完成 HQC 的隔離評估清單，再按需要安排 Mac 開發環境；不要把環境交付誤當成生產部署批准。