AES-256-GCM 是一種經過認證的對稱式加密器，它使用 256 位元金鑰加密文字，並附加一個 128 位元的驗證標籤，因此任何錯誤的金鑰或遭竄改的位元組都會導致解密失敗，而不是產生損壞但仍可讀取的結果。線上工具若標榜支援 AES-GCM，會將這些基本元件包裝成便於攜帶的套件，讓您可以複製、傳送，之後再用同一組密碼重新開啟。Lizely 上的 AES Encryption Online 工具即遵循此模式:您輸入明文，選擇一組至少 12 個 UTF-8 位元組的通行密碼，頁面便會回傳一個自含的 JSON 文件，內容包含全新的 salt、全新的 12 位元組 IV，以及附加 GCM 標籤的 base64url 密文。若要還原過程，您只需將該套件貼回頁面並提供相同的密碼;工具會重新衍生出金鑰，執行同樣的 Web Crypto 基本元件，僅在驗證標籤相符時才會印出原始文字。每一步皆透過 Web Crypto API 在您的瀏覽器分頁中執行，因此密碼與明文絕不會離開您當前使用的裝置。
為何 AES-256-GCM 適合用於線上文字交換
AES-256 是 Advanced Encryption Standard 區塊加密器的 256 位元金鑰變體。Galois/Counter Mode(GCM)在該加密器之上疊加一層驗證標籤，使每個加密位元組都繫結到一個 128 位元的指紋，該指紋衍生自金鑰、IV、密文及任何關聯資料。當接收方解密時，Web Crypto 會重新計算該指紋，只要有一個位元被更改，就會拒絕釋出任何明文。
對線上工作流程而言，此配對至關重要，因為在非認證模式下有兩種狀況會反覆出錯:錯誤的金鑰會悄悄產生看似文字的亂碼，遭竄改的區塊則會在不知情的情況下蒙混過關。GCM 將這兩種失敗模式合併為單一明確的「驗證失敗」回應，這正是線上工具在面對從未知管道貼上套件的使用者時，所應該展現的行為。
此工具也滿足第三項實務需求。AES-GCM 是 W3C Web Cryptography Level 2 規格明確指名的 AEAD 構造，因此網頁可透過標準的 Web Crypto 基本元件執行該加密器，而無需捆綁自訂實作。這使得 JavaScript 的暴露面得以縮小，並避免手工編寫加密程式碼時常出現的細微錯誤。
此工具所產生 JSON 套件的結構剖析
加密作業並不會回傳原始的密文區塊，而是回傳一個 JSON 物件，設計上便於複製、透過聊天傳送、儲存至磁碟，或保存在備忘錄中。各欄位皆明確標示，以便審查者稽核其構造。
| 欄位 | 類型 | 用途 |
|---|---|---|
| v | integer | 套件版本，目前為 1 |
| alg | string | 加密器標籤，AES-256-GCM |
| kdf | string | 金鑰衍生函式，PBKDF2-SHA-256 |
| iter | integer | PBKDF2 迭代次數，210000 |
| salt | base64url | 16 位元組隨機 salt，非機密 |
| iv | base64url | 12 位元組隨機初始向量，非機密 |
| ct | base64url | 經認證的密文，並於末端附加 128 位元的 GCM 標籤 |
salt、IV 與密文皆依據 RFC 4648 採用未填補的 base64url 編碼。解密路徑上的驗證作業會在請求 Web Crypto 進行認證與解密之前，先檢查標籤、數值限制、欄位語法、精確的 salt 與 IV 長度，以及最低密文長度。此檢查閘門正是用於在任何金鑰資料曝光前，先行拒絕人工編輯或截斷的套件。
此格式為此工具所專屬。雖然加密基本元件已標準化，但環繞的 JSON 版面配置並非通用檔案格式，因此另一套系統若要互通，必須重現相同的 UTF-8 處理方式、PBKDF2 參數、AES-GCM 標籤位置，以及 base64url 編碼。保持整個套件不變是最簡單的規則，這也是為何加密輸出與解密輸入必須逐位元組相符的原因。
在瀏覽器中使用 AES-256-GCM 加密文字
AES Encryption Online 的加密功能僅需幾個步驟，即可將明文與密碼轉換為 JSON 套件。
- 開啟 AES Encryption Online 頁面，確認已選取 Encrypt 分頁。
- 將您要保護的明文貼上或輸入至輸入區。工具接受任何 UTF-8 文字，包括表情符號與附加口音符號的字元。
- 輸入一組獨特的密碼。介面強制要求至少 12 個 UTF-8 位元組，並接受更長的通行密碼，這是工具用以抵禦薄弱設定的最低門檻。
- 點擊 Encrypt 按鈕。頁面會產生一個全新的 16 位元組 salt 與全新的 12 位元組 IV，以 PBKDF2-SHA-256 進行 210,000 次迭代以衍生出 256 位元的 AES 金鑰，接著透過 Web Crypto API 執行 AES-GCM，並擷取 128 位元的標籤。
- 從輸出區複製完整的 JSON 套件。請將整個區塊視為單一不可分割的產出物，切勿刪除欄位或重新排版。
- 透過任何便利的管道(聊天、電子郵件、工單)傳送套件，並透過另一條獨立的安全管道(例如電話通話或密碼管理員的分享連結)交付密碼。
明文、密碼、衍生金鑰與最終結果皆停留在當前分頁內。由於完全沒有上傳，因此密碼的唯一複本就是您自行保管的那一份。
開啟 JSON 套件並還原原始文字
解密作業與加密作業互為鏡像，但驗證更為嚴格，因為任何單一欄位遭修改皆會產生誤導性的輸出。典型流程如下:
- 將工具切換至 Decrypt，並將未經變動的套件貼入輸入區。
- 輸入產生該套件時所使用的相同密碼。相同的 UTF-8 位元組必須抵達相同的 PBKDF2 設定，否則衍生出的金鑰將無法相符。
- 點擊 Decrypt。頁面會使用儲存的 salt 與儲存的迭代次數重新衍生金鑰，接著請求 Web Crypto 使用儲存的 IV 與密文進行認證與解密。
- 若標籤相符，即可讀取還原後的明文。若驗證失敗，工具會回報失敗訊息且不傳回任何部分明文，這正是 GCM 防止靜默亂碼觸及使用者的保證。
由於 salt 與 IV 隨套件一同傳遞，解密作業完全可攜:任何裝置只要具備相同工具並擁有正確密碼，皆可開啟該文件，不受最初加密地點的限制。
AES-GCM 所能保證的，以及無法涵蓋的部分
GCM 是一種輕量級的 AEAD 構造，其保證與此工具的使用方式契合無間。
| 特性 | AES-256-GCM 所提供的內容 |
|---|---|
| 機密性 | 明文對未持有密碼者隱藏不可見 |
| 完整性 | 任何對密文或標籤的修改皆會導致解密失敗 |
| 真實性 | 128 位元標籤將密文繫結至產生該密文的金鑰 |
| 新穎性 | 每次執行皆產生新的隨機 salt 與 IV，因此即使明文與密碼皆相同，仍會產生不同的套件 |
| 重放安全性 | 未提供——攻擊者若擷取到有效的套件，可將其重放給仍信任該套件的任何對象 |
承諾完整性的同一列，同時也暴露出薄弱密碼的風險。PBKDF2-SHA-256 會將單一猜測透過 210,000 次 SHA-256 雜湊運算加以延伸，藉此墊高從猜測密碼暴力破解金鑰的成本，但它無法將一個簡短、重複使用、外洩或可預測的密碼化為強固的機密。一組源自可信密碼管理員、具備高熵值的獨特通行密碼，才是賦予此構造得以捍衛之物的關鍵。若您希望深入了解，《AES-256 Encryption:Inside an Authenticated GCM Package》指南以更完整的篇幅，逐一剖析相同的各項保證。
需留意的運作限制
此頁面專為小型文字片段、展示用途、受控交換及相容性實驗而設計。它並非託管式保險箱、企業金鑰管理服務、加密備份系統，亦不可取代經過審閱的應用層級加密設計。
部分威脅落在加密邊界之外。具備內容指令碼存取權的瀏覽器擴充功能，在分頁開啟期間可讀取明文與密碼。剪貼簿管理員會在您複製後保留套件的複本。共用電腦、螢幕擷取，以及套件被複製後的存放位置，皆超出 AES-GCM 所能保護的範圍。當周邊裝置不受信任時，清除敏感內容並關閉分頁是務實的緩解措施。
此外，亦不提供密碼復原、託管代理、帳號備份或伺服器端金鑰管理。一旦密碼遺失，該套件將永遠無法讀取，無論加密技術多麼強健皆然。以相同密碼重複加密相同文字時，因 salt 與 IV 經過隨機化，會刻意產生不同的套件，這正是對抗基於等值特性的流量分析所期望的屬性。此實作已依據 NIST SP 800-38D GCM 出版物中所述的測試向量進行核對，因此轉換結果與標準一致，但這些檢查僅認證加密器與套件版面配置，並不涵蓋瀏覽器、裝置、密碼選擇，或其周邊的工作流程。
延伸閱讀:AES Encryption Online:Encrypted Text as a JSON Package。