AES-256 加密將 AES 區塊加密器、256 位元秘密金鑰、GCM（Galois/Counter Mode）認證模式，以及由 PBKDF2 衍生的金鑰結合在一起，把任何明文字串轉換成單一自含的 JSON 套件，不論透過電子郵件、聊天或檔案傳輸，都不會洩露原始位元組。名稱中的 256 代表秘密金鑰長度。AES 本身是由美國國家標準與技術研究院（NIST）標準化的區塊加密器，一次處理 128 位元的區塊。使用 256 位元金鑰時，AES 會執行 14 輪的替代、置換與混合運算，而這正是原始 FIPS 197 出版品中保留給最高機密等級的配置。GCM 在該區塊加密器之上疊加認證加密，並回傳單一密文 blob，其中已包含 128 位元的認證標籤，因此對套件的任何修改或任何錯誤的密碼，都會在顯示任何明文之前失敗。該套件以 base64url 欄位宣告演算法、金鑰衍生參數、鹽、初始化向量以及認證密文——這是接收端重現相同 256 位元金鑰並驗證結果所需的一切。
AES-256 加密實際上做了什麼
AES-256 加密作業接受一個密碼與一段明文字串，然後回傳一個只能用同一組密碼解開的套件。其背後的數學機制是搭配 256 位元秘密金鑰的 AES 區塊加密器，並透過 GCM——一種結合機密性與內建完整性檢查的模式——加以套用。在底層，密碼會被轉換為 UTF-8 位元組，並透過 PBKDF2-SHA-256 延伸成 256 位元金鑰；接著該金鑰會連同一個全新的 12 位元組初始化向量與明文一起交給 AES-GCM。輸出是單一密文 blob，其末端已附加 128 位元的 GCM 認證標籤。
256 位元金鑰長度的特殊之處，在於攻擊者必須暴力破解的搜尋空間規模。256 位元金鑰共有 2^256 種可能的數值，這個數字大到無論是任何傳統電腦，或在目前已發表的提案下的任何量子電腦，都無法在有意義的時間內列舉出來。這就是為什麼 AES-256 被推薦用於保護最高機密等級的資料，包括政府與金融工作負載。AES-128 與 AES-192 使用相同的演算法但輪數較少；它們在幾乎所有實際用途上仍然安全，但 256 位元變體是長期保存時較為保守的預設選擇。
AES 金鑰長度一覽
AES 接受三種金鑰長度，但皆對應相同的 128 位元區塊。下表摘要了 FIPS 197 與 NIST SP 800-38D 為每種變體所定義的數值。
| 變體 | 金鑰長度（位元） | 輪數 | 區塊大小 | 建議的 GCM IV |
|---|---|---|---|---|
| AES-128 | 128 | 10 | 128 位元 | 96 位元（12 位元組） |
| AES-192 | 192 | 12 | 128 位元 | 96 位元（12 位元組） |
| AES-256 | 256 | 14 | 128 位元 | 96 位元（12 位元組） |
本工具使用的變體是最右邊那一列：256 位元金鑰、14 輪，以及 12 位元組的 IV。在較小的變體之間選擇 AES-256 並不會改變套件格式或 GCM 標籤長度；它只是提高了猜測由密碼衍生的金鑰所需付出的暴力破解成本。
認證 JSON 套件的結構
每次加密會產生一個 JSON 物件。各欄位會宣告所使用的演算法、金鑰衍生方式與迭代次數，然後以 base64url 字串承載鹽、初始化向量與密文。去除空白後，其結構如下：
"version": 1, "alg": "AES-256-GCM", "kdf": "PBKDF2-SHA-256", "iter": 210000, "salt": "<base64url>", "iv": "<base64url>", "ct": "<base64url>"
salt 欄位剛好是 16 個原始位元組（16 × 8 = 128 位元），以不含填補字元的 base64url 編碼；iv 欄位剛好是 12 個原始位元組（12 × 8 = 96 位元）；ct 欄位承載加密後的位元組，並在末端附加 128 位元的 GCM 認證標籤——這正是 W3C Web Cryptography 規範針對 AES-GCM 輸出所記錄的格式。Web Cryptography Level 2 規範是本工具在金鑰匯入、衍生、加密與解密時所依循的參考文件。
由於該套件本身就是完整的受保護承載內容，因此必須以產生時的格式原樣傳輸與儲存。移除任何欄位、將空白正規化為帶填補的標準 Base64，或從密文上修剪掉標籤，都會導致解密步驟無法通過其嚴格的驗證。請將此套件視為不透明文字，切勿編輯。
從密碼到 256 位元金鑰
在頁面上輸入的密碼並非 AES 實際使用的金鑰。本工具會以所提供的密碼（UTF-8 編碼）與隨機產生的 16 位元組鹽執行 PBKDF2-SHA-256，並重複進行 210,000 次基於 SHA-256 的衍生運算，以產生一個無法匯出的 256 位元 AES 金鑰。該迭代次數高到足以讓每一次密碼猜測在一般硬體上所費不貲，這正是 PBKDF2 在本系統中所扮演的角色。
鹽本身不需要保密。它的作用在於確保兩位恰好選用相同密碼的使用者，最終仍會得到不同的衍生金鑰，並防止攻擊者把一次猜測的成本分攤到多個套件上。因此，鹽會與 IV 一起儲存在套件本身內部，在解密時必須存在，但公開展示是安全的。
PBKDF2 無法挽救一個薄弱的密碼。短小、重複使用或可預測的秘密，仍是本系統中最容易被突破的環節，因此本工具要求至少 12 個 UTF-8 位元組，並接受更長的 passphrase。從值得信賴的密碼管理工具中取用一組獨特且高熵的 passphrase，才是讓 AES-256 真正發揮作用的務實做法。
如何在瀏覽器中加密與解密文字
開啟 AES Encryption Online 頁面。加密與解密模式位於同一個介面，因此同一個工具即可涵蓋工作流程的兩個階段。
- 選擇 Encrypt，在訊息欄位中輸入明文，並輸入一組至少 12 個 UTF-8 位元組的唯一密碼。
- 執行加密。頁面會衍生 AES-256 金鑰，使用 AES-GCM 加密，並在畫面上顯示產生的 JSON 套件。
- 將整個 JSON 套件原樣複製，並透過另一個獨立的安全管道保存密碼——切勿將兩者貼在同一則訊息、工單或筆記中。
- 若要還原明文，請切換至 Decrypt，將完全相同的套件貼回輸入欄，並輸入同一組密碼。
- 執行解密。若密碼與位元組皆正確，您將會看到原始明文；若有任何錯誤，頁面會回報認證失敗，且不會顯示任何部分結果。
只要持有密碼與套件，任何人都可以反向執行相同的流程。兩次執行皆完全在瀏覽器中透過 Web Crypto API 進行，而明文、密碼、衍生金鑰與解密結果皆會保留在當前頁面上。
為何 GCM 認證至關重要
認證是 AES-GCM 中多數通俗說明會略過的那一半。AES 本身僅提供機密性，即使金鑰錯誤仍能解出位元組——只是解出來的會是亂碼。GCM 會額外產生一個 128 位元的標籤，該標籤是根據密文與 IV 共同計算出來的，並直接與金鑰綁定。以錯誤的密碼解密時無法重現該標籤，因此頁面會停止並回報認證失敗，而不會回傳一段誤導性的字串。
同一個標籤也正是能偵測竄改的關鍵。若密文、IV 或鹽在傳送端與接收端之間有任何一個位元組被變更，重新計算出來的標籤將會不相符，解密會在顯示任何明文之前被拒絕。正是這項特性讓 JSON 套件成為一份可驗證的回執，而非脆弱的密文 blob，也正是它讓套件格式在 ct 欄位末端保留標籤空間的原因。
對於想在 AES-GCM 之上額外加入獨立 keyed digest 的使用者，相關的 HMAC 產生指南會逐步說明如何在明確掌控金鑰的情況下產生 SHA-256、SHA-384 與 SHA-512 標籤。AES-GCM 內建的標籤已能用單一步驟涵蓋機密性與完整性這類相同的威脅模型，因此除非應用程式要求使用獨立的加密基元，否則通常不需要再疊加 HMAC。
實際限制與本工具不涵蓋的功能
本工具的界線就是其執行所在的瀏覽器分頁。剪貼簿管理程式、瀏覽器擴充功能、螢幕擷圖、共用電腦，以及您將套件貼上的目的地，全都落在 AES-256 的保護範圍之外，仍可能造成資料外洩，因此當周邊裝置不受信任時，請清除頁面並關閉分頁。
本工具不提供密碼復原、託管機制、帳號，也沒有伺服器端金鑰管理。一旦遺失密碼，即使網站經營者也無法開啟該套件。請以對待明文本身的謹慎程度來對待密碼。
本頁面適用於小型文字片段、展示用途、受控的交換作業，以及相容性實驗。它並非託管式保險箱、企業級金鑰管理服務，也不是加密備份系統。若需處理較大的檔案、金鑰輪替，或經稽核的應用層級加密，您需要的是經審查的基礎設施，而非單一的瀏覽器表單。本工具的實作已對照 NIST 的 AES-GCM 測試向量進行驗證，包括空明文認證案例與完整的零區塊加密案例，且 base64url 欄位遵循 RFC 4648——這證明了所定義的轉換與套件不變式，但並非認證背後的裝置或密碼選擇。