AES 加密從零講起

一句話概括：AES 是全球標準的分組密碼 — 在 128、192 或 256 位金鑰下打亂 16 位元組的分組 — 而你選擇執行它的模式（GCM、CBC、CTR、ECB）決定了這些分組如何連結、IV 有什麼用、以及篡改能否被察覺；除非有特殊理由，請直接選 GCM。

AES 本身是什麼（FIPS 197）

分組密碼。AES（Rijndael 設計，2001 年由 NIST 標準化為 FIPS 197）每次恰好加密 16 位元組。金鑰長度 — 16、24 或 32 位元組 — 決定了是 AES-128、-192 還是 -256，以及內部輪數（10、12、14 輪）。每一輪通過替換表、行移位和列混合，把分組與由你的金鑰派生的輪金鑰混合。現實中不存在攻破演算法本身的實用攻擊：真實世界的失敗幾乎總是模式、IV 或金鑰管理的失誤 — 這正是本頁餘下部分要講的內容。

為什麼需要模式？因為訊息很少恰好是 16 位元組。模式負責把一次次分組加密粘合起來：ECB 只是獨立地加密每個分組；CBC 把每個分組與上一段密文異或；CTR 像流密碼一樣加密一個計數器再與資料異或；GCM 在 CTR 之上增加了認證標籤。AES 本身不變 — 模式決定了你能得到什麼樣的安全保證。

金鑰與密碼。AES 金鑰是 16、24 或 32 個隨機位元組。人類密碼做不到這一點：本頁的“密碼”選項用 PBKDF2-HMAC-SHA256 派生出真正的金鑰（預設 600,000 次迭代，即 OWASP 2023 基線 — KDF 細節見 HMAC 生成器）。永遠不要把密碼字串直接當 AES 金鑰用：其熵值只相當於其長度的一小部分。

四種模式對比

模式	IV / nonce	完整性	說明
GCM	12 位元組，每條訊息唯一	有 — 96..128 位標籤	AEAD：各處的推薦預設（TLS 1.3、SSH、檔案格式）。還支援 AAD。
CBC	16 位元組，不可預測	無	PKCS#7 填充；經典但需要搭配 MAC。填充預言機漏洞是 CBC 的經典陷阱。
CTR	16 位元組初始計數器	無	無填充、類似流密碼、支援隨機訪問；同一金鑰下重用 nonce 會洩露明文異或明文。
ECB	無	無	相同分組 → 相同密文。即“ECB 企鵝”演示。僅用於相容。

IV 規則一段話講完。IV 不是秘密 — 把它隨密文一起傳送即可 — 但它的唯一性要求各不相同：CBC 要求 IV 不可預測；GCM 和 CTR 只要求同一金鑰下絕不重用同一 nonce（GCM 重用更糟：會洩露認證金鑰）。本頁的“隨機 IV”按鈕使用瀏覽器的安全隨機數發生器；“全零”按鈕是為了復現測試向量，不是給真實訊息用的。

填充。CBC 和 ECB 需要完整的分組，因此 PKCS#7 填充會追加 1..16 個位元組，每個都等於填充長度。這就是 CBC 密文最多會增長 16 位元組的原因，也是用錯誤金鑰解密通常報填充錯誤的原因。CTR 和 GCM 類似流密碼、無需填充 — 密文長度與明文長度完全相等（試試 CTR 模式下的“示例”：43 位元組進，43 位元組出）。

CFB 和 OFB（剩下的兩種經典模式）本頁未實現：它們像 CTR 一樣是流式的，卻沒有任何優於 CTR 的地方，主要殘存於老協議中。

GCM 增加了什麼（AEAD、標籤、AAD）

認證加密。GCM = CTR 加密 + 對密文、IV 和 AAD 計算 GHASH 認證器。輸出的標籤是一切的指紋：密文、IV 或 AAD 哪怕變了一個位元，標籤就對不上了，因此接收方可以證明訊息完整且來自持有金鑰的人。CBC+HMAC 只有在組合方式正確時（先加密後 MAC）才能達到同樣效果 — 而 GCM 天生就做對了。

AAD。附加認證資料以明文形式傳輸，但被標籤覆蓋：協議頭、檔名、演算法識別符號。接收方必須提供完全一致的 AAD 位元組，否則標籤校驗失敗 — 這正是其意義所在。

標籤長度。預設的 128 位標籤是推薦值；更短的標籤（96..120 位）用抗偽造能力換體積。低於 96 位時 GCM 的安全性證明迅速退化，所以本頁到此為止。

nonce 災難。同一金鑰下重用 12 位元組的 GCM nonce，會洩露兩條訊息明文的異或以及認證子金鑰 — 此後該金鑰下所有未來訊息都可被偽造。無法保證唯一性的系統應使用抗 nonce 誤用變體（AES-GCM-SIV，RFC 8452）。

基準向量 — 在本頁復現它們

第一行是著名的 FIPS 197 單分組示例；其餘由獨立的原生實現（Node.js 呼叫 OpenSSL）生成，並已在本頁引擎上覆核。把金鑰、IV 和輸入貼上到頁面中即可復現每一行。

用例	輸入	預期輸出
AES-128 單分組（FIPS 197 風格）	key `000102..0f`, plaintext `00112233..ff`	69c4e0d86a7b0430d8cdb78070b4c55a
AES-128-GCM	key `000102..0f`, IV `606162..6b`, plaintext `0011..ef` ×2	ct 275f095bedfda377063fee326128892188377b410698ed03a022b9971bb4bdbe, tag 87ea7770714048977de2fd8dac645ecf
AES-256-GCM，同上但加 AAD `deadbeef`	key `000102..1f`	ct eacab966ff15e518f48f5390be502fbc2756ccee0dcfff36a282c50bf5593ae7, tag aead900e895c88252d0388d7aefce5c8
AES-256-CBC	key `000102..1f`, IV `101112..1f`, plaintext `0011..ef` ×2	0e2392dd6f690b44a5a1b4fdff3b7f83cb9ab59d9900119cc5f83e062d95fb643b1a94b514ea2f3b95f84c900b5c98a8
AES-256-CTR（輸入同上 CBC）	43-byte plaintext → 43-byte ciphertext	e9d2cdb9f661359178ed366dfa3a4671f8e20efd723f090eb7d1d524d480fd3c

常見錯誤

因為 ECB 不需要 IV 而用它。方便正是陷阱：分組模式直接洩露進密文（加密一張點陣圖，圖片依然可見）。ECB 只對單分組或恰好 16 位元組的隨機金鑰可接受 — 實踐中永遠不該主動選擇它。
重用 nonce/IV。在 GCM 或 CTR 的同一金鑰下，這是唯一一個能讓一切同時崩壞的錯誤。基於計數器的系統（本頁的“隨機 IV”按鈕）就是為了杜絕這種可能而存在的。
把 IV 當秘密。它不是。把它與密文一起儲存或傳輸。藏起來毫無收益，反而誘使重用。
把密碼直接當金鑰。"hunter2hunter2hunter2hunter2" 是 32 位元組，但不是 256 位熵 — 它只是一個加了填充的詞典單詞。請用 PBKDF2 派生（本頁內建），或生成隨機金鑰。
以為 CBC 能發現篡改。翻轉 CBC 密文中的一個位元，解密會“成功”地得到被悄悄破壞的明文。只有 GCM 的標籤（或顯式的 HMAC）能讓篡改現形。
比較兩段 GCM 密文是否相等。隨機 nonce 下，同一段明文每次加密的結果都不同 — 這是特性不是缺陷。確定性加密是另一種專用工具。

常見問題

AES-128 還安全嗎，還是必須用 256？面對現實的攻擊者兩者都安全；已知最好的攻擊也只削掉安全餘量的很小一角。AES-256 主要用於長期機密和抗量子的安心（Grover 演算法把金鑰強度減半，AES-256 相當於約 128 位）。

為什麼 openssl enc 不支援 GCM？enc 命令早於 AEAD 出現，沒有地方攜帶標籤；OpenSSL 3.3 為此新增了專門的 aesgcm 命令。本頁的 GCM 輸出把標籤單獨放在一行，方便你明確地搬運兩者。

什麼是金鑰包裹（AES-KW）？一種專門用來加密其他金鑰的模式，以固定 64 位塊處理並自帶完整性校驗。本頁不提供它，因為它的輸入輸出都是“金鑰形狀”而非“訊息形狀” — 誤用才是常態。

為什麼我的 CTR 密文和明文一樣長，CBC 卻更長？CTR 和 GCM 是流式的（無填充）；CBC/ECB 用 PKCS#7 填充到完整的 16 位元組分組。長度差異是設計使然，不是缺陷。

能解密在別處加密的資料嗎？可以，只要你知道確切的模式、金鑰、IV（GCM 還需要標籤）。本頁的輸出行精確記錄了所有引數，便於在工具之間移植 — 上方的 OpenSSL 框給出了對應的命令列。

AES 加密 / 解密