2026 年版（後量子）密碼學的正確答案

12 Oct 2026

向開發者發布《密碼學正確答案》，如今已成為一項傳統。Colin Percival 在 2009 年開始這項傳統，Thomas Ptacek 在 2015 年接續，之後Latacora 在 2018 年和2024 年繼續發表。

現在更新似乎為時尚早，但變化實在太大。後量子轉型的時間表在 2026 年初大幅改變，如今大家一致認為必須在 2029 年前完成。2029 年！我們只剩三年！

好消息是，儘管你可能聽過其他説法，對稱式密碼學不會有問題，因為 Grover 並不重要。壞消息是，與 2018 年相比，所有非對稱密碼學方面的建議都已改變；即使與 2024 年相比，大部分也已改變。

以下建議假設你不受任何特定合規制度限制，不過大部分建議都符合 FIPS 140。¹ 如果你需要遵循 CNSA 2.0 之類更嚴格的規定，自然會知道。只需按需要替換即可。

最後，別忘記 2026 年另一項重大變化：大型語言模型現在非常擅長找出程式錯誤。「使用你負擔得起的最佳模型進行審查」如今已穩穩成為密碼學的正確答案之一，與沿用已久的經典建議「使用記憶體安全語言」並列。

如果你趕時間，以下是速查表：

加密資料：如果你使用雲端服務，請用 KMS。否則，使用 XAES-256-GCM 或 XChaCha20Poly1305，並採用隨機 nonce。如果要加密的資料超過幾 MB，請使用 Cobblestone-128。
對稱式金鑰長度：不用太操心。如果必須選擇，就用 256 位元金鑰。
對稱式「簽章」：HMAC-SHA-256。
雜湊演算法：SHA-2 仍然適用，但如有需要，請使用真正的 multihash（SequenceHash）。
隨機 ID：32 個隨機位元組，即 256 位元隨機數。
密碼處理：Argon2id 或 scrypt。不過，你有考慮改用通行金鑰嗎？
金鑰交換：在安全、標準的協定中使用 X25519+ML-KEM-768。
非對稱式加密：使用 (MLKEM768-X25519，即 X-Wing、HKDF-SHA256、AES-128-GCM) 的 HPKE，或使用支援後量子金鑰的 age。
非對稱式簽章：ML-DSA-44。
網站或用戶端－伺服器應用程式安全：如果你使用雲端服務，請使用其 ALB/NLB。否則，請使用 rustls、Go 的 crypto/tls、BoringSSL、AWS-LC 或 s2n-tls，並配合主流且已更新的 ACME 用戶端。
線上備份：使用 restic，並設定一個長而隨機的密碼。

現在進入正題。

加密資料

如果你使用雲端服務，請用 KMS。否則，使用 XAES-256-GCM 或 XChaCha20Poly1305，並採用隨機 nonce。如果要加密的資料超過幾 MB，請使用Cobblestone-128。

Percival，2009：AES-CTR 搭配 HMAC。
Ptacek，2015：NaCl/libsodium 預設方案，或 ChaCha20Poly1305，或 AES-GCM。
Latacora，2018：KMS，或 XSalsa20+Poly1305。
Latacora，2024：KMS，或 NaCl 的 secretbox，或 XChaCha20Poly1305。

Latacora 關於為何及何時使用雲端 KMS 的論據依然可靠，不妨從這裏開始。

如果你在本機加密，應選用一種 AEAD，讓你無須擔心追蹤 nonce，或計算已加密的訊息數量；因此，你需要至少 128 位元的隨機 nonce。²

NaCl/libsodium 的 secretbox 只是包裹較少見 AE 構造（XSalsa20+Poly1305）的一層薄薄包裝，因此我建議改用XAES-256-GCM或 XChaCha20Poly1305。前者是標準 KDF 與 AES-GCM 的高效組合，包裝成支援延伸 nonce 的 AEAD；即使你的程式庫沒有以這個名稱提供，你也可以透過 KDF 和 AES-GCM API 組合出來。³

只有在確定不會用同一把金鑰加密超過十億則訊息時，才適合使用搭配隨機 nonce 的一般 AES-GCM 和 ChaCha20Poly1305。如果你所需的所有地方都支援 AES-GCM-SIV，它也是不錯的 AEAD 選擇，但這種情況不太可能。有些更新的選項具備金鑰承諾等優良特性，但目前仍未普及。

既然你使用 AEAD，不妨把情境資訊放進額外資料，例如你要為其加密的用戶 ID，或通訊協定的版本。選擇任何不具保密性、而且解密時肯定仍然可知的資料即可。

如何處理大型訊息非常重要，KMS 無法替你解決這個問題。不要把一則大型訊息交給 AEAD，否則你可能被迫在解密時驗證明文之前先處理或儲存它。絕對不要使用未經驗證的串流密碼。你應該改用 STREAM（它不是串流密碼，而是一種在串流上使用 AEAD 的方式……我知道，我知道，這名字糟透了）。可選方案很多——事實上太多了——令人遺憾的是，當中沒有任何一種獲得公認的共識。Tink 有一種，libsodium 有一種，AWS Encryption SDK 有一種，FLOE 是其中一種，age 也有一種，還有其他不少選擇。我推薦Cobblestone-128，這是源自 TLS 的 STREAM 變體，已在 pyca/cryptography 中提供，並即將加入 Go 標準程式庫（目前則可在filippo.io/cobblestone取得）。⁴

避免使用：未經驗證的模式（CBC、CTR、原始串流密碼）；隨機 96 位元 nonce，除非你已花很多時間思考要加密多少則訊息；自行設計 AEAD 構造。

對稱金鑰長度

不用太費心。如果要選，就用 256 位元金鑰。

Percival, 2009：256 位元 AES 金鑰。
Ptacek, 2015：256 位元金鑰。
Latacora, 2018：256 位元金鑰。
Latacora, 2024：256 位元金鑰。

請記住，Grover 演算法實際上無關緊要，而且不存在 128 位元暴力破解攻擊。不過，256 位元金鑰可以排除多目標攻擊，這一點不錯。

但不要因此作出其他決定。例如，推薦的 Cobblestone 套件使用 128 位元金鑰，這完全沒問題，因為它仔細分析過多目標攻擊。同樣地，不要為了強制使用 256 位元金鑰而更改 TLS 程式庫預設的密碼套件偏好設定；沒有這個需要。

AES-256 比 AES-128 慢，因為 Rijndael 將輪數與金鑰長度掛鈎，這點令人遺憾；不過在實際應用中，這大概不成問題。

避免：128 或 256 位元以外的長度；過分在意長度；不均勻的金鑰（例如直接把密碼或 ASCII 十六進位字串用作金鑰）。

對稱式「簽署」

HMAC-SHA-256。

Percival, 2009：HMAC。
Ptacek, 2015：HMAC。
Latacora, 2018：HMAC。
Latacora, 2024：HMAC。

HMAC 萬歲。

只要始終驗證原封不動的位元組字串，而非需要重新計算的內容，就能避免正規化及解析器對齊錯誤。

正確：

{
    "inner": "{\"foo\":123}",
    "hmac": "MbPsZq7QGCllJgDnSSy/cyM10HjqiVu35UO7yyY5d3w="
}

先檢查 HMAC，然後只處理、儲存或轉送 {"foo":123}。

錯誤：

{
    "foo": 123,
    "hmac": "MbPsZq7QGCllJgDnSSy/cyM10HjqiVu35UO7yyY5d3w="
}

如果你本來就有理由使用它們底層的雜湊函數，可以使用 KMAC 或 keyed BLAKE3。HMAC-SHA-512 也可以。

記得使用專用的常數時間函數比較驗證標記。

避免：自行實作 YoloMAC、加密雜湊，以及 Poly1305 或 GMAC 等獨立的一次性 MAC。

雜湊演算法

SHA-2 仍然適用，但如有需要，請使用真正的多重雜湊。

Percival, 2009：SHA-256 (SHA-2)，並為 SHA-3 作好準備。
Ptacek, 2015：SHA-2。
Latacora, 2018：SHA-2。
Latacora, 2024：SHA-2。

如果可以使用，最佳選擇仍然是 SHA-512/256，因為它不會受到長度延伸攻擊。否則，SHA-256 和 SHA-512 都可以。⁵

SHA-3 沒有必要（因為 SHA-2 已經足夠），而且速度慢，⁶但並非錯誤。如果你已經因為 ML-KEM 和 ML-DSA 而使用 Keccak (SHA-3)，並想用它來進行雜湊處理，就從 SHAKE128 取得 32 個位元組。

BLAKE2 現在是個奇怪的選擇。BLAKE3 的速度非常快，但它相當複雜，也不常見，因此你應該有充分理由使用它，也應該有充分理由信任你的實作。

多重雜湊是指需要同時對多個項目進行雜湊處理。例如，對一列中的多個欄位，或對檔名連同檔案內容進行雜湊處理。這比聽起來更講究，因此請使用 SHA-2 搭配 SequenceHash，或使用 SHA-3 搭配 TupleHash (SP 800-185)。

避免：SHA-1、MD5、所有其他雜湊函數、自行實作多重雜湊，以及截短至少於 256 位元，除非密碼學專家告訴你碰撞並非問題。

隨機 ID

32 個隨機位元組，亦即 256 位元隨機數。

Percival, 2009：256 位元隨機數。
Ptacek, 2015：256 位元隨機數。
Latacora, 2018：256 位元隨機數。
Latacora, 2024：256 位元隨機數。

請注意，UUIDv4 和 rand.Text 等 API 只會產生約 128 位元的值。除非你需要超過 280 萬億 (2⁴⁸) 個唯一值，否則通常已經足夠。256 位元雖然綽綽有餘，但何樂而不為。

使用作業系統的 CSPRNG：Linux 上使用 getrandom，Windows 上使用 ProcessPrng，macOS 和 BSD 上使用 arc4random_buf，網頁上使用 getRandomValues。優質的程式庫會為你封裝這些功能。

避免：非密碼學 PRNG、OpenSSL 的使用者空間隨機數產生器、haveged、CPU 抖動熵。⁷

密碼處理

Argon2id 或 scrypt。不過，你有考慮過改用通行密鑰嗎？

Percival, 2009：scrypt 或 PBKDF2。
Ptacek, 2015：scrypt，其次是 bcrypt，必要時再用 PBKDF2。
Latacora, 2018：scrypt，其次是 Argon2，再來是 bcrypt，必要時再用 PBKDF2。
Latacora, 2024：Argon2id，其次是 scrypt，再來是 bcrypt，必要時再用 PBKDF2。

我的前人所説的仍然完全正確：「你可以向牆上擲飛鏢，從中選一個。」我剔除了 bcrypt，因為 72 位元組截斷會造成問題。有一個建議：你可以向審計人員主張 scrypt 符合 FIPS 140 規定，因為它實際執行的 KDF 步驟是 PBKDF2，而這正是他們要求的。我聽説這樣行得通。

參數方面，忽略 RFC 9106；它似乎想摧毀你的正式環境。Argon2id 可使用 m=64 MiB, t=2, p=1（libsodium 的 INTERACTIVE 預設值），scrypt 則使用 N=2^16, r=8, p=1。兩者使用相同的記憶體，但 scrypt 會多耗用約 1.5 倍 CPU 時間，GPU 時間則只有 ¼，這就是應優先選用 Argon2id 的原因。如果你要進行非互動式金鑰衍生，可以按你能接受的程度提高 Argon2id 的 m，然後提高 t（scrypt 則提高 N⁸）。

更重要的是，你真的需要密碼嗎？如果只用來登入，可否改用防網絡釣魚的通行密鑰？也可以用電郵魔法連結作為後備方案？或者直接支援 SSO（前提是採用 OIDC，而非 SAML）？

（請注意，到了 2026 年，通行密鑰仍未具備後量子安全性。這大致上沒有問題。它們仍能防止網絡釣魚和憑證填充攻擊。量子攻擊者唯一能做的，就是在取得某個網站的資料庫或截取一次登入後，登入該特定網站。）

避免：一般雜湊；把時間花在思考密碼雜湊上，而非專注於通行密鑰；容易遭網絡釣魚的電郵登入變體。⁹

金鑰交換

在安全、標準的協定中使用 X25519+ML-KEM-768。

Percival, 2009：2048 位元 Group #14，生成元為 2。
Ptacek, 2015：可能仍是 DH-2048，或 NaCl。
Latacora, 2018：可能甚麼也不用，或 Curve25519。
Latacora, 2024：X25519+ML-KEM-768。

Latacora 2018 年版本的答案，提出「為甚麼你身為開發者會去想這件事，這到底是甚麼意思？！」這個問題，確實説得對。不要自行設計金鑰交換協定。只要在 TLS 選用 X25519MLKEM768，在 SSH 選用 mlkem768x25519-sha256，及／或在 HPKE 和 age 選用 MLKEM768-X25519。如果你確實需要取得一些金鑰，而且知道自己在做甚麼，TLS 和 HPKE 都有「exporter」可用來衍生這些金鑰。

不具 PQ 能力的方案因「先收集、後解密」攻擊，正構成持續且迫切的風險；而 PQ 替代方案則由不切實際（HQC-KEM、FrodoKEM），到既不切實際又有缺陷（Classic McEliece）不等。

金鑰交換採用 ECC 混合方案的成本低至值得一用；事實上，ML-KEM 通常會與 ECDH 一同部署。不過，如果選擇或實作混合方案，會令你在傳統、非 PQ 金鑰交換上多停留哪怕一個月，就立即直接改用純 ML-KEM-768。

P-256+ML-KEM-768 也不錯，只是較少見。多年來，NIST P 曲線的名聲一直欠佳，但我認為 90% 的原因是它們出現時，我們還不太懂得做好密碼工程（以及……姑且説，是受到非NPOV式宣傳的影響）。針對 NIST P 曲線上 ECDH 的攻擊，幾乎沒有任何一種會影響臨時金鑰交換。

避免：任何名稱中沒有 ML-KEM 或 X-Wing（特定的 X25519+ML-KEM-768 組合器）的方案。

非對稱加密

採用 (MLKEM768-X25519（又稱 X-Wing）、HKDF-SHA256、AES-128-GCM) 的 HPKE，或 使用 PQ 金鑰的 age。

Percival, 2009：RSAES-OAEP 配合 SHA-256、MGF1+SHA-256，以及指數 65537。
Ptacek, 2015：NaCl。
Latacora, 2018：NaCl/libsodium（box / crypto_box）。
Latacora, 2024：情況較複雜，等待成熟的 PQ 方案。

這是近年來進步最大的答案之一，因為現在我們已有標準可用於混合加密：HPKE。（「混合」指非對稱加密 + 對稱加密，而非傳統密碼學 + 後量子密碼學；名稱一詞多義，真好啊。）

MLKEM768-P256 也是可用的 KEM 選項，但支援較少。如果你手上只有純 ML-KEM-768，也可以。所有 KDF 和 AEAD 選項也都沒問題。

如果訊息很大，請採用 Cobblestone 相同的分塊方式，以多次按順序呼叫 HPKE Seal/Open 取代 AEAD。

請注意，PQ HPKE KEM 令人非常懊惱地仍處於草案階段。¹⁰ 更糟的是，它們不必要地分散在四份草案中，令我不得不撰寫 filippo.io/hpke-pq。不過，我讓作者們鄭重保證不會更改傳輸格式，之後我們便都在各自的密碼學程式庫中推出了這些方案，所以你可以而且應該使用它們。

如果你需要更高階的方案，支援多個接收者或 CLI，請使用 age¹¹，搭配其新推出、以 age1pq 為前綴並基於 MLKEM768-X25519 的金鑰。YubiKey 和 Secure Enclave 等外掛程式也正陸續加入 PQ 支援。

避免使用：同樣地，避免任何非 ML-KEM 方案（尤其是 RSA 和 NaCl 的 box¹²）、OpenPGP，以及加密電郵。

非對稱式簽章

ML-DSA-44。

Percival，2009：RSASSA-PSS，使用 SHA-256、MGF1+SHA-256，以及指數 65537。
Ptacek，2015：NaCl、Ed25519 或 RFC 6979。
Latacora，2018：NaCl 或 Ed25519。
Latacora，2024：如果有效期短，使用 Ed25519；否則使用 Ed25519+ML-DSA-65。

在 2026 年 1 月，我本來會叫你先觀望，然後一切開始加速發展。認證也需要轉用 PQ。

直接使用 ML-DSA-44。如果訊息需要預先雜湊，請使用「external-μ (Mu)」簽署，而非 HashML-DSA。只以 32-byte 種子的形式儲存金鑰。

兩種 PQ 替代方案是 FN-DSA，它目前仍卡在美國商務部某個環節；以及基於雜湊函數的 SLH-DSA。後者適用於某些專門用途，但速度慢、體積大，而且實作支援不普遍。

為甚麼不採用混合式方案或「複合方案」？混合式認證比混合式金鑰交換更複雜，效用也較低。我需要撰寫一篇長文探討這個問題，簡單來説，要麼你已有金鑰輪替策略，可以在極不可能發生密碼分析破解時，改回使用 RSA/ECDSA/Ed25519；要麼你的時間跨度很長，應假設量子電腦終究會破解其中的傳統部分。

此外，ML-DSA 確實比前代方案優秀得多。它具備防護式隨機性（比隨機或確定性 nonce 都更好）、內置上下文、SUF-CMA 等額外特性，而且相對容易實作和測試。

既然我推薦 ML-KEM-768，為甚麼選用 -44 參數集？與 ML-KEM-512（NIST 類別 1）不同，ML-DSA-44 屬於 NIST 類別 2，其安全級別本身已高於 128-bit，並留有一定餘量。

不採用複合方案這條規則的唯一例外是 SSH 金鑰。OpenSSH 10.6 選用了 ssh-mldsa44-ed25519。我認為他們做錯了，但你偏離這裏的主流做法，也會是個錯誤。

非對稱簽章用得過多，尤其如今簽章成本不低，應盡量避免使用。可以考慮是否能改用簡單的 HMAC。或許可以用隨機工作階段權杖取代已簽署的 JWT。如果你確實想公開承諾某項內容，可以考慮使用透明度日誌，藉此實現更具實際用途的不可否認性（而且若將簽章成本分攤至多個證明，整體大小可能更小）。

避免：所有非 PQ 選項，例如 RSA/ECDSA/Ed25519、有狀態簽章（LMS/XMSS）、HashML-DSA、ML-DSA「半展開金鑰」、複合簽章、OpenPGP。

網站或用戶端－伺服器應用程式安全性

如果你使用雲端服務，請使用其 ALB/NLB。否則，可使用 rustls、Go 的 crypto/tls、BoringSSL、AWS-LC 或 s2n-tls，並配合一個廣受歡迎且已更新的 ACME 用戶端。

Percival, 2009：網站使用 OpenSSL，應用程式使用自訂 RSA 協定。
Ptacek, 2015：使用 OpenSSL；如果可以，則使用 BoringSSL。或者直接使用 AWS ELB。
Latacora, 2018：使用 AWS ALB/ELB 或 OpenSSL，並配合 Let’s Encrypt。
Latacora, 2024：使用 AWS ALB/ELB 或 OpenSSL，並配合 Let’s Encrypt。

不建議使用 OpenSSL，可能會是我最不切實際的建議，但 OpenSSL 多年來持續作出令人費解且有問題的選擇。pyca/cryptography 的作者在一篇詳述 OpenSSL 問題的長文中，將其概括為：

我們對 OpenSSL 的使用體驗，過去幾年一直每況愈下。

他們甚至曾在 2025 OpenSSL Conference 上發表演講（!?），看來徒勞無功。批評 OpenSSL 的不只他們：伺服器端有 HAProxy，用戶端則有 curl。

我建議使用 rustls 或 Go 的 crypto/tls，¹³；兩者都具備記憶體安全性。如果必須使用 C，BoringSSL 和 AWS-LC 都是維護得相當完善的 OpenSSL 分支；與 BoringSSL 不同，後者有具版本號的發行版本。如果不需要與 libssl 相容，s2n-tls 和 rustls-ffi 也是值得留意的選項。

無論使用哪種方案，請確保優先採用 X25519MLKEM768 金鑰交換；這需要 TLS 1.3。你的雲端負載平衡器可能要求你選擇 PQ 安全性政策。在 RHEL 9 及其衍生版本上，你需要選擇啟用。

以往的清單將網站和用戶端－伺服器應用程式分開列出。我把兩者合併，因為現今兩者都會使用相同的 TLS 堆疊。不同之處在於 PKI。對於通訊兩端都由你控制的應用程式，可以考慮自行建立 ML-DSA-44 X.509 憑證，並以自簽方式簽署，或由私有根憑證簽發。網站則應設定一個廣受歡迎、支援完善的 ACME 用戶端，並保持更新。Merkle 樹憑證將於 2027 年推出，你應做好準備，以便納入這項轉換。

避免：自行編寫傳輸協定、曾在核心職責上出過問題的 TLS 函式庫（GnuTLS¹⁴、Mbed TLS¹⁵ ¹⁶ ¹⁷、wolfSSL¹⁸ ¹⁹ ²⁰ ²¹ ²² ²³ ²⁴ ²⁵、Botan²⁶ ²⁷）、不太主流的 TLS 函式庫、3.5 版之前的 OpenSSL（首個支援 X25519MLKEM768 的版本）、如可行，避免使用任何 OpenSSL、TLS 1.0–1.1、如可行，避免使用 TLS 1.2，以及自行編寫 ACME 用戶端。

線上備份

restic 配上長而隨機的密碼。

Percival, 2009：Tarsnap。
Ptacek, 2015：Tarsnap。
Latacora, 2018：Tarsnap。
Latacora, 2024：Tarsnap。

我很久以前檢查過 restic 的加密，當時覺得它有點古怪，但做得不錯。它完全採用對稱式加密，所以不怕量子電腦。看來自那時起沒有任何改變。如果你需要雲端儲存空間，rsync.net 為 restic 用戶提供一個「secret」方案，而且支援只追加模式。

我們都喜歡 Tarsnap，而我現在感覺自己好像背叛了前輩……但它的非對稱密碼學層全都採用 RSA。嚴格來説，我認為真正會出問題的只有權限較低的金鑰：只寫金鑰可以解密封存檔，而唯讀金鑰可以偽造封存檔。伺服器驗證使用 HMAC，而 RSA 公開金鑰從不會傳送到伺服器。從這個角度來看，Tarsnap 與 restic 一樣安全；對於一項在 2008 年設計的方案來説，這成就令人印象深刻。不過，在量子電腦即將出現之際，這感覺就像一個重大的安全隱患。

圖片

竟然可以直接走近這東西，真是有點不可思議。

The Colosseum, at night, pictured from the ground looking up.

歡迎在 Bluesky @filippo.abyssdomain.expert 或 Mastodon @filippo@abyssdomain.expert 關注我。

FIPS 140 在模組驗證方面仍有一些非常糟糕的部分（執行階段自我測試、完整性檢查，以及愈趨混亂的 RNG 問題），但如今實際採用的加密演算法「其實相當不錯」。 ↩
你可能會看到 GCM 可以使用 128 位元 nonce，但這樣一來，它就沒有獨立的 CTR 計數器，而採用不同 GCM nonce 的訊息可能會共用 CTR 密鑰流，令分析變得更複雜。 ↩
先説明：XAES-256-GCM 是我的設計，但目前已有多個第三方實作，包括 Google 的 Tink 函式庫中的實作；Amazon Web Services 有一份安全性分析，而且它已由 Microsoft 用於官方 SDK。 ↩
再次説明，這是我的設計，但它已獲得足夠多的外部採用，因此我覺得可以放心推薦。 ↩
在 64 位元機器上，SHA-512/256 和 SHA-512 應該會因區塊較大而比 SHA-256 快；但目前 SHA-256 的硬件支援更普遍，因此實際上 SHA-256 會更快。兩者都很快，所以你大概不會在意。 ↩
部分原因在於，NIST 作出了一些選擇，令 SHA3-256 的安全性嚴格達到 SHA-256 的水平，即使 SHA-256 的安全性已超出所需。SHA-256 和 SHA3-256 均有 128 位元的碰撞抗性，以及 256 位元的第二原像抗性。兩種抗性各有 128 位元便已足夠，而 256 位元的 SHAKE128 輸出正好能達到這一點。可惜的是，它沒有 SHA 名稱。TurboSHAKE128 (RFC 9861) 會更理想，但它既不屬於 FIPS 140，也未廣泛普及。 ↩
FIPS 140 地獄圈之外的人似乎都未有留意，但 NIST 的新規定現在要求 FIPS 140 模組必須有一個「內部」熵源。如果你的 FIPS 140「模組」只是一件軟件……你會怎樣做？大家的答案都是「CPU 抖動」：執行一個緊密迴圈，存取未快取記憶體並取得高解像度時間戳，希望 CPU 與主記憶體之間的頻率差異能令測量結果難以預測。依我看，這是自模組完整性雜湊以來 FIPS 140 最糟糕的一環，而且會傷害到人。唯一合理的做法是先照樣完成整套流程，然後在最後一刻把結果與核心熵混合，就像 Go 所做的一樣。然而，比起單用 CPU 抖動，這樣做更難向驗證實驗室交代，所以我擔心正式環境中會有很多系統只用純 CPU 抖動。 ↩
Argon2id 的參數大致如你所想；scrypt 的參數則不是如此。 ↩
帶有不透明隨機權杖、並在開啟連結的瀏覽器中登入的連結，很難遭網絡釣魚利用。在發起登入的瀏覽器中登入的連結，則很容易遭網絡釣魚利用。短數字代碼遭網絡釣魚利用的難度則屬中等。（你可以透過 Broadcast Channel API，將權杖從新分頁傳送至原來的分頁，兼得兩者的優點。） ↩
我曾在另一個場合表示，一個認真的工程社羣應該會就此作事後檢討：我們浪費了原本用於過渡至後量子密碼學的五年中的兩年，結果制定出的規格與我們在 2024 年已有的相比，毫無改變。不過，這留待日後再談。 ↩
再再説明，坦白披露：這是我的設計，但這個選擇相當沒有爭議。 ↩
我真的不明白為甚麼前任會推薦 NaCl 的 box。它是一個極其容易誤用且層次很低的 API，卻佯裝成高階、安全的 API。 ↩
最後再説一次，坦白披露：我是 crypto/tls 的維護者。 ↩
CVE-2020-13777，GnuTLS 3.6.4–3.6.13：工作階段票證金鑰全為零，破壞 TLS 1.2 的機密性，並可繞過 TLS 1.3 的身分驗證。 ↩
CVE-2023-45199，Mbed TLS 3.2–3.4：在 TLS 1.3 握手中透過過大的 key share，可在驗證前遠端執行程式碼。 ↩
CVE-2026-34873，Mbed TLS 3.5.0–4.0.0：TLS 1.3 工作階段恢復可讓人冒充用戶端。 ↩
CVE-2026-25835，Mbed TLS 2.18.0–3.6.5 和 4.0.0：RNG 狀態在 fork 時被複製，因此父程序與子程序會產生相同的隨機值。 ↩
CVE-2026-5194，wolfSSL 3.12.0–5.9.0：只要提供 ML-DSA 或 Ed25519 簽署演算法識別碼，以及一個針對零長度摘要的簡單 ECDSA 簽章，便可偽造 ECDSA 憑證的簽章。 ↩
CVE-2026-5501，wolfSSL 5.9.0 及之前版本：OpenSSL 相容層在提供任何有效的終端實體憑證作為「中間憑證」時，會跳過葉憑證的簽章檢查。 ↩
CVE-2026-11310，wolfSSL 5.8.4–5.9.1：OpenSSL 相容層會將呼叫者提供的不受信任中間憑證視為信任錨。 ↩
CVE-2026-11999，wolfSSL 5.7.4–5.9.1：OpenSSL 相容層會接受任何長於 100 的最大路徑深度的憑證鏈，即使鏈未到達信任錨。 ↩
CVE-2026-55960，wolfSSL 5.6.4–5.9.1：一律接受原始公鑰取代憑證，繞過驗證。 ↩
CVE-2026-93302，wolfSSL 5.3.0–5.9.2：受信任對等方憑證以名稱而非公鑰配對。 ↩
CVE-2026-89136，wolfSSL 5.6.0–5.9.2：用戶端仍會接受伺服器未經請求提供的原始公鑰，繞過驗證。 ↩
CVE-2026-89135，wolfSSL 5.8.4–5.9.2：OpenSSL 相容層的憑證鏈驗證失敗後，攻擊者的 CA 會被永久加入原生 TLS、OCSP 和 CRL 檢查所用的信任儲存區。 ↩
CVE-2026-34580，Botan 3.11.0：若終端實體憑證的 DN 與受信任根憑證相符，該憑證便會被當作根憑證接受。 ↩
CVE-2026-34582，Botan 3.11.1 之前的版本：TLS 1.3 伺服器會在收到 Finished 前處理應用程式資料，因此用戶端可以完全跳過 Certificate、CertificateVerify 和 Finished，全面繞過用戶端驗證。 ↩