AES 加密解密工具

AES（Advanced Encryption Standard，進階加密標準）是目前全球最廣泛使用的對稱加密演算法，被美國國家安全局（NSA）批准用於保護絕密級資訊。AES 由比利時密碼學家 Joan Daemen 和 Vincent Rijmen 設計的 Rijndael 演算法演變而來，於 2001 年由美國國家標準與技術研究院（NIST）正式發布，用於替代已經不再安全的 DES 演算法。 AES 採用分組加密方式，每組固定 128 位元（16 位元組），支援 128、192 和 256 位元三種金鑰長度，分別對應 AES-128、AES-192 和 AES-256 三個安全級別。金鑰越長，安全性越高，但加解密速度會略有下降。作為對稱加密演算法，AES 使用相同的金鑰進行加密和解密，這使得它在效能上遠優於非對稱加密演算法。 AES 的應用場景非常廣泛：在網路安全領域，TLS/SSL 協定使用 AES 保護網頁瀏覽和電子郵件傳輸；在儲存安全領域，BitLocker、FileVault 等磁碟加密工具採用 AES 加密使用者資料；在資料庫安全領域，許多資料庫系統支援 AES 欄位級加密；在物聯網領域，AES 也被廣泛用於裝置間的安全通訊。本工具支援 AES 的全部 6 種加密模式（ECB、CBC、CFB、OFB、CTR、GCM）和 5 種填充方式，滿足各種加密需求。

AES（進階加密標準）於 2001 年 11 月由 NIST 以 FIPS 197 發布，經過 1997 年開始的五年公開競選，共有 15 個候選演算法。最終由比利時密碼學家 Joan Daemen 和 Vincent Rijmen 設計的 Rijndael 勝出，擊敗了 Twofish、Serpent、RC6 和 Mars 等決賽入圍者。AES 取代了 DES（FIPS 46，已於 2005 年撤銷），現在是全球部署最廣泛的對稱區塊加密演算法：它存在於 TLS 1.2/1.3、IPsec、BitLocker、FileVault、OpenSSL 的預設 `aes-256-gcm`、Linux 核心的 dm-crypt、Apple 的 CryptoKit 以及 Android 的 Keystore 中。NSA 於 2003 年批准 AES-256 用於最高機密（TOP SECRET）保護（Suite A），使 AES 成為首個被允許用於美國最高機密等級的公開加密演算法。區塊大小固定為 128 位元（16 位元組）；金鑰長度為 128、192 或 256 位元，分別對應 10、12 或 14 輪運算。 每一輪（最後一輪除外）對 4x4 位元組狀態執行四個操作：SubBytes 套用固定的 16x16 S-Box（0x63 = 01100011 位於第 6 行第 3 列——S-Box 的構造方式為 GF(2^8) 中的乘法反元素加上仿射變換，以破壞代數結構）；ShiftRows 將第 0 行旋轉 0 位元組、第 1 行旋轉 1 位元組、第 2 行旋轉 2 位元組、第 3 行旋轉 3 位元組；MixColumns 在 GF(2^8) 上將每欄乘以固定的循環 MDS 矩陣（矩陣形式的多項式 0x03 * x）；AddRoundKey 與輪金鑰進行 XOR 運算。最後一輪省略 MixColumns。輪金鑰來自 Rijndael 金鑰排程：共 11/13/15 個 128 位元的輪金鑰，透過 RotWord（向左旋轉 1 位元組）、SubWord（套用 S-Box）和與 Rcon[i] = [0x01, 0x02, 0x04, ..., 0x80, 0x1b, 0x36] *2^(i-1) 在 GF(2^8) 上的 XOR 產生。本頁面的 `aes-js` 函式庫以純 JavaScript 執行全部四個步驟，且與 OpenSSL 的 libcrypto 位元組相容。 頁面提供五種區塊加密模式。ECB 獨立加密每個 16 位元組區塊：相同的明文區塊會產生相同的密文區塊，從而洩漏結構（著名的 ECB 企鵝影像在加密後仍保留輪廓，因為像素模式在加密後依然存在）。CBC 在加密前將每個明文區塊與前一個密文區塊進行 XOR 運算；第一個區塊與 IV 進行 XOR。CTR 透過加密遞增計數器（nonce || counter，兩者各為 128 位元區塊的 64 位元半部）並將金鑰串流與明文進行 XOR，將 AES 轉變為串流加密——支援隨機存取和平行加密。GCM 是 CTR 加上 GHASH（GF(2^128) 上的通用雜湊認證器），產生 16 位元組的認證標籤附加在密文之後。GCM 是 TLS 1.3（RFC 8446）和大多數現代 API（Node 的 `crypto.createCipheriv('aes-256-gcm', ...)`）的預設 AEAD。CFB 和 OFB 是較舊的串流加密模式，保留以維持相容性。 IV 使用陷阱是最常見的生產環境錯誤。GCM 搭配 96 位元（12 位元組）IV 是 NIST 推薦的配置（RFC 5288、NIST SP 800-38D §5.2.1.1）：12 位元組 IV 被視為計數器，GHASH 在 J0 = IV || 0x00000001 上計算。在 CTR 模式下重複使用 IV 會洩漏明文 XOR（C1 XOR C2 = P1 XOR P2——單次選擇明文攻擊即可還原兩則訊息）。在 GCM 下重複使用 IV 更為嚴重：攻擊者可以還原認證子金鑰 H，並為任意訊息偽造標籤（此攻擊出自 Joux 2006，也是 NIST 禁止在未嚴格保證唯一性的情況下使用隨機 96 位元 IV 的原因）。本頁面使用 `crypto.getRandomValues(new Uint8Array(12))` 為 GCM 產生 12 位元組 IV，為 CBC/CFB/OFB 產生 16 位元組 IV，隨機金鑰按鈕使用相同的 CSPRNG，確保每次加密都使用全新的材料。 本工具完全在瀏覽器中使用 aes-js（純 JavaScript AES 實作）完成加解密。不存在 Web Crypto / SubtleCrypto 回退路徑——無論負載大小，所有運算都透過 aes-js。

• AES 是 FIPS 197（2001），透過 NIST 公開競選從 15 個候選演算法中選出；Rijndael 擊敗了 Twofish、Serpent、RC6 和 Mars。區塊大小固定為 128 位元；金鑰長度 128/192/256 位元分別執行 10/12/14 輪。本頁面透過 aes-js 的 AES_128、AES_192 和 AES_256 建構函式支援全部三種。
• 四步輪函數：SubBytes（256 位元組 S-Box，為 GF(2^8) 反元素加上仿射變換）、ShiftRows（各列移位 0/1/2/3 位元組）、MixColumns（GF(2^8) 上使用 0x03 多項式的 MDS 矩陣乘法）、AddRoundKey（與輪金鑰 XOR）。最後一輪省略 MixColumns。相同演算法、相同金鑰 = 相同密文——AES 是確定性的。
• ECB 不安全，因為相同的明文區塊會產生相同的密文區塊（著名的「ECB 企鵝」影像保留了輪廓）。CBC 是安全的經典模式；CTR 增加了平行性；GCM 增加了認證功能，是 TLS 1.3 的預設模式（RFC 8446）。CFB 和 OFB 是為了向後相容而保留的串流加密模式。
• PKCS#7 填充：差 1 位元組 → 15 個 0x0f 位元組 + 1 個 0x10 位元組；差 2 位元組 → 14 個 0x0e 位元組 + 2 個 0x0f 位元組，依此類推。最後一個位元組的值就是填充長度，因此去填充是明確的。串流模式（CTR/CFB/OFB/GCM）完全跳過填充。ZeroPadding 在資料以 0x00 結尾時會產生歧義——不要使用。
• GCM 是 AEAD：密文加上 16 位元組認證標籤，透過 GF(2^128) 上的 GHASH 計算，使用 H = AES_K(0^128)。AAD（額外認證資料）涵蓋標頭但不對其加密。96 位元 IV（RFC 5288）被視為計數器；128 位元 IV 會經過 GHASH 推導 J0——安全性相同，速度稍慢。
• IV 重複使用是災難性的。CTR IV 重複使用會洩漏 P1 XOR P2（二次填充）。GCM IV 重複使用（Joux 2006）允許攻擊者還原 H 並偽造標籤。本頁面使用 `crypto.getRandomValues`（CSPRNG）產生 IV，在一個工作階段內絕不重複使用，並將 IV 前置於密文中，讓解密端無需帶外狀態即可取回。
• AES 金鑰產生：本工具的「產生隨機金鑰」按鈕使用瀏覽器提供的 `crypto.getRandomValues`（CSPRNG）。AES 輪函數計算透過 aes-js（純 JavaScript 實作）完成，在相同金鑰、IV、填充設定下與 OpenSSL libcrypto 位元組級一致。
• 旁通道現實：純 JS 的 AES 不是常數時間的（索引 S-Box 陣列會洩漏時序）。Web Crypto 的 AES 以原生程式碼執行且為常數時間。對於高安全性工作負載（HSM、伺服器端 KDF）應優先使用原生路徑；對於瀏覽器內學習工具，aes-js 就足夠了，因為輸入已經在頁面記憶體中。遷移路徑：雜湊演算法從 SHA-1 遷移到 SHA-256，加密演算法從 DES 遷移到 AES，加密模式從 ECB 遷移到 GCM。