AES-256-GCM 將 256 位元金鑰與 128 位元認證標籤配對使用，而 AES Encryption Online 會把每一次執行結果打包成一個自給自足、版本為 1 的 JSON 套件，方便瀏覽器複製、儲存或稍後解密。這個工具完全免費，透過瀏覽器的 Web Crypto API 在本機執行，並且絕不會把明文、密碼、衍生金鑰或解密結果上傳到 Lizely。每次執行都會使用全新的 16 位元組隨機 salt、全新的 12 位元組隨機初始化向量，以及搭配 210,000 次迭代的 PBKDF2-SHA-256 來衍生一把不可匯出的 256 位元 AES 金鑰。加密與解密刻意設計成對稱操作：加密產生 JSON 套件，解密則讀取該套件；若認證失敗，工具只會回報錯誤，絕不會輸出部分明文。由於每次執行都會重新產生 salt 與 IV，即使使用相同密碼加密同一段明文，每次產生的套件也會不同，這正是讓 JSON 格式能在不同瀏覽器之間搬移的特性。欄位配置是這個工具專屬的，因此任何其他系統若要互通，必須重現完全相同的 PBKDF2 參數、AES-GCM 標籤位置，以及 base64url 欄位。
免費的 AES 工具如何在你的瀏覽器中運作
搜尋 AES 加密服務時，結果通常會分成三種模式：免註冊的網頁應用程式在瀏覽器內執行、可嵌入程式碼的下載函式庫，或是由伺服器端點代為處理金鑰的服務。AES Encryption Online 屬於第一種模式，而且更進一步，將所有密碼學運算都保留在當前的分頁中。明文、密碼、衍生金鑰以及解密輸出僅存於頁面記憶體中，直到你關閉分頁為止；資料不會送交後端、不需要註冊帳號，也不會附加任何遙測資訊。這個工具刻意不做為託管式保險庫或企業級金鑰管理服務，也無法找回遺失的密碼，因為密碼從未寫入套件，也從未跨越網路傳輸。
加密回傳的套件是一個純 JSON 物件，只要保持位元組完全一致，你可以貼到電子郵件、即時通訊、工單或檔案中。解密則是其反向操作：貼上未經更動的套件、提供相同的密碼，只有在每一個位元組、標籤、長度與認證標籤都完全相符時，同一個分頁才會還原出原始明文。由於格式本身已宣告其內容與預期行為，你不需要安裝軟體、複製函式庫或架設伺服器，即可在不同機器之間往返傳送一小段文字。
將文字加密為可攜的 JSON 套件
這是工作流程的一半，負責產生稍後可以搬移或儲存的套件。介面提供單一條加密路徑，只需要幾個必要輸入，並且只有在輸入格式正確足以成功時才會回報套件。
- 選擇 Encrypt，然後在輸入區中輸入或貼上你想保護的明文。
- 輸入一組至少 12 個 UTF-8 位元組的唯一密碼；建議使用來自可信賴密碼管理工具的較長密碼短語。
- 執行 AES-256-GCM 加密。工具會產生全新的 16 位元組 salt 與全新的 12 位元組 IV，使用 PBKDF2-SHA-256 搭配 210,000 次迭代衍生一把不可匯出的 256 位元金鑰，以 AES-GCM 加密，並把 128 位元認證標籤附加到密文之後。
- 複製完整的 JSON 套件，並在透過另一個安全管道（例如不同的通訊軟體、密碼管理工具或離線通話）傳送密碼時，保持套件內容完全不變。
這個階段有兩項重要注意事項。首先，套件一旦產生就無法辨識其內容，編輯欄位、替換 salt 或更換 IV 都會導致下次解密時認證失敗。其次，由於每次執行都會重新產生 salt 與 IV，即使使用相同密碼加密同一段明文，每次產生的套件都會不同。這是刻意的設計，也是套件能夠跨平台搬移的原因之一：它帶有未來解密所需的所有非機密隨機性。
將 JSON 套件解密回明文
解密是對稱的流程，負責消化上面產生的套件。它假設套件在機器之間未被修改，且密碼是透過與套件本身不同的管道送達。
- 選擇 Decrypt，然後將 JSON 套件原封不動地貼到輸入區，不要編輯、重新排版或替換任何字元。
- 輸入加密時使用的相同密碼，特別留意空白字元與任何 UTF-8 字元。
- 執行解密。工具會驗證每個標籤與數值限制，檢查 salt 與 IV 長度是否正確，確認密文長度下限，請瀏覽器驗證套件認證，只有在 128 位元 GCM 標籤驗證通過後才會釋出明文。
- 若密碼錯誤或套件中有任何位元組被修改，工具會回報認證失敗，絕不會回傳部分明文。
這些嚴格的驗證規則並非裝飾品。移除迭代次數、把 base64url 欄位標準化為帶填補的 Base64、用視覺相似的字元替換某個字元，或插入格式不認得的欄位，都會在任何金鑰衍生執行之前被標記出來。這能避免損毀或遭竄改的套件悄悄產生錯誤結果，並提供清楚的信號讓你重新檢查傳輸過程。
JSON 套件內部：欄位、編碼與驗證
套件配置是在 JSON 本身中宣告的，因此四個密碼學要素與四個支援欄位都會明確命名。下方表格顯示呼叫端可以依賴的內容，以及每個值的編碼方式。
| 欄位 | 意義 | 編碼與限制 |
|---|---|---|
| v | 格式版本 | 整數，目前為 1 |
| kdf | 金鑰衍生函式 | 字串 "PBKDF2-SHA-256" |
| iter | PBKDF2 迭代次數 | 整數，210000 |
| cipher | 加密器識別 | 字串 "AES-256-GCM" |
| salt | 隨機密碼 salt | Base64url，16 位元組（未填補，依 RFC 4648） |
| iv | 初始化向量 | Base64url，12 位元組，每次加密皆重新產生 |
| ct | 已認證密文 + 128 位元 GCM 標籤 | Base64url，明文位元組後接著標籤 |
解密時會依序讀取這些欄位，檢查標籤與數值限制，然後才讓 Web Crypto API 進行認證並解開內容。加密模式與迭代次數都是標準化的：AES-GCM 定義於 NIST 出版品中，Web Crypto 原語則遵循 W3C 瀏覽器層級密碼學規範。然而 JSON 欄位配置本身是 AES Encryption Online 專屬的；其他系統只有在重現相同的 UTF-8 處理、相同的 PBKDF2 參數、相同的 GCM 標籤位置、相同的 base64url 編碼，以及相同的欄位名稱時，才能互通。如果想進一步了解如何把這個工作流程延伸到較長的訊息或重複的交換，請參閱 在瀏覽器中使用 AES-256 線上加密與解密文字。
密碼長度、PBKDF2 及其實際效用
JSON 套件中除了密碼以外，每個值都是公開可見的。salt、IV 與迭代次數並非機密，因為它們的作用是確保唯一性與金鑰延伸，而非保密。讓套件具有強度的，是所有設計良好的 AES 工作流程所仰賴的同一件事：把高熵值的密碼短語，透過刻意提高運算成本的金鑰衍生程序處理。介面拒絕長度少於 12 個 UTF-8 位元組的輸入，底層的 PBKDF2-SHA-256 工作因子固定為 210,000 次迭代，讓每一次猜測都耗費足夠的成本，以遏止隨性的攻擊。
這些控制項並不會把弱密碼變成強密碼。短、重複使用、已外洩或可預測的密碼短語，無論套用多少次迭代仍然薄弱，因為迭代次數只是以一個常數倍數減緩猜測速度，而密碼熵值才是以指數規模放大攻擊者的工作量。誠實的規則其實很無聊：使用可信賴的密碼管理工具產生唯一的密碼短語，將其視為其他任何根機密般對待，並且絕不要把套件與密碼同時貼到同一個聊天視窗、工單或文件中。
可見的隨機性也不是漏洞。AES-GCM 僅要求在給定金鑰下，每個初始化向量必須唯一，因此每次執行都產生全新的隨機 IV，正是防止相同密碼下的兩個套件產生任何有用等號訊號的關鍵特性。如果你曾經在兩次執行中看到完全相同的套件位元組，代表隨機性來源出了問題，而非密碼學本身出了問題。
這個工具刻意不做的事
免費的瀏覽器頁面並非企業級金鑰管理系統，這點值得直說。AES Encryption Online 不會儲存你的密碼、不會衍生還原金鑰、不會託管機密，也不會跨裝置同步歷史紀錄。這裡沒有帳號、沒有備份，也沒有任何操作員可以代替你解開套件。這個工具的密碼學界線僅止於當前分頁內的 Web Crypto API；剪貼簿管理員、瀏覽器擴充套件、螢幕擷取、共用電腦，以及你貼上套件的目的地，全部都落在那條界線之外。
這就是為什麼上面的工作流程堅持要為密碼另闢一條安全管道，並建議在裝置不再受信任時關閉分頁。同時也是為什麼這個工具最適合用於小段文字、示範、雙方已知的受控交換與相容性實驗，而非用來取代經過審閱的應用層級密碼學設計。對於上述較大型任務，正確的答案是一個已針對你實際部署需求完成稽核的系統。
如果你想要與本文引用的標準互相對照，底層的 AES-GCM 行為定義於 NIST SP 800-38D，瀏覽器層級的實作則遵循 W3C Web Cryptography 規範。這個工具本身已對照 NIST AES-GCM 向量進行驗證，包括一段空明文認證案例與一個全零區塊案例，足以確認定義的轉換與套件不變式如預期運作，但這並非對你的密碼或裝置下任何結論。
延伸閱讀：如何在瀏覽器中執行二進位與文字的轉換。