AES Encryption Online 將一段純文字與一組密碼，透過目前瀏覽器分頁內的 Web Crypto API，轉換成一個自帶驗證機制的 AES-256-GCM JSON 封包，全程不會將密碼、衍生金鑰或解密結果上傳到網路。其保護機制來自以 256 位元金鑰於 Galois/Counter Mode（GCM）下執行的進階加密標準（AES），並搭配 PBKDF2-SHA-256 金鑰衍生（210,000 次迭代）、每次執行皆新產生的一組 16 位元組隨機 salt，以及一組 12 位元組的隨機初始化向量（IV）。最終產生的封包會帶有一個 128 位元的驗證標記（authentication tag），使得任何被竄改的位元組、被變更的欄位，或任何錯誤的密碼，都會在明文被揭露之前就導致解密失敗。由於兩個操作皆在本機執行，因此這套工具最適合被理解為一個可控、透明、適用於小型文字片段的封套，而不是一個託管式的保險箱、帳號系統，或企業級的金鑰管理服務。
AES-256-GCM 線上加密究竟做了什麼
進階加密標準（AES）是在 NIST FIPS 197 中標準化的對稱式區塊加密演算法，被廣泛用於保護 HTTPS 流量、加密檔案系統、磁碟映像檔以及資料庫欄位。「對稱」代表加密與解密使用的是同一把秘密金鑰，因此整個機制的安全性完全取決於該金鑰是否能保持私密。AES 支援 128、192 與 256 位元的金鑰；AES Encryption Online 一律使用 256 位元的變體，具備最大的內部金鑰排程（key schedule），也讓任何針對猜測密碼的暴力破解攻擊付出最高的代價。
區塊加密無法單獨安全地處理任意輸入，因此必須以「操作模式」加以包覆。AES Encryption Online 使用 Galois/Counter Mode（GCM），這是一種已於 NIST SP 800-38D 中標準化的認證式加密模式。GCM 同時產生密文與一個 128 位元的驗證標記，該標記會針對加密後的位元組及所有相關中繼資料進行計算。這個標記讓解密端得以確認加密後資料未遭竄改，因此無論是密碼錯誤、封包中的某個位元被翻轉，或任一欄位被移除，都會產生明確的驗證失敗，而不會靜悄悄地產生出損壞的明文。
由於同一組密碼無法直接餵給 AES，因此工具會先將其透過 PBKDF2（搭配 SHA-256 與 210,000 次迭代）處理，並混入一組對每次加密而言皆不重複的隨機 16 位元組 salt。PBKDF2 能提高攻擊者在竊得封包後猜測密碼的成本，但它無法挽救一組過短、重複使用、外洩或可預測的密碼。最低要求長度為 12 個 UTF-8 位元組，而一組由可信賴的密碼管理工具所產生的高熵值、獨特密碼短語，仍是整個工作流程中最關鍵的一道防線。
深入解析 AES Encryption Online 的 JSON 封包
加密的輸出是一份自給自足的 JSON 文件。每個欄位都有明確用途，而這套嚴謁的結構是本工具特有的。其他系統只有在重現相同的 UTF-8 處理、PBKDF2 參數、AES-GCM 標記位置、base64url 編碼與欄位名稱時，才能讀取這個封包。移除任何欄位、將 base64url 改為帶填補的 base64，或重新排列密文與標記的順序，都會在密碼演算法本身被呼叫之前就破壞驗證流程。
| 欄位 | 用途 | 編碼方式 |
|---|---|---|
| version | 格式識別碼，目前為 1 | 整數 |
| cipher | 演算法標籤，AES-256-GCM | 字串 |
| kdf | 金鑰衍生函式，PBKDF2-SHA-256 | 字串 |
| iterations | PBKDF2 工作因子，210000 | 整數 |
| salt | PBKDF2 使用的隨機 16 位元組 salt | Base64url，無填補 |
| iv | 隨機 12 位元組的初始化向量 | Base64url，無填補 |
| ciphertext | 加密後的位元組，並附加 128 位元的 GCM 標記 | Base64url，無填補 |
salt 與 IV 之所以以明文儲存，是因為其作用在於確保唯一性，而非保密。AES-GCM 在同一把金鑰與 IV 組合被重複使用時會出現災難性的弱點，因此本工具每次執行都會產生全新的隨機值，而非要求使用者自行設定。試圖編輯封包、置入舊的 salt、IV 或密文，將會破壞封包，且永遠不是有效的還原手段。
使用 AES-256-GCM 線上加密文字
當您需要一個可攜、以密碼保護的文字封包，以便貼入聊天、提交至儲存庫，或與其他檔案一同存放時，請使用 AES Encryption Online 工具。請依照下列步驟以執行一次乾淨的加密。
- 選擇「加密（Encrypt）」，將明文貼上或輸入到輸入欄位，並輸入一組至少 12 個 UTF-8 位元組的唯一密碼。強烈建議使用由可信賴的密碼管理工具所產生的更長密碼短語。
- 執行加密。瀏覽器會產生全新的隨機 16 位元組 salt 與 12 位元組 IV，以 PBKDF2-SHA-256（210,000 次迭代）衍生一把不可匯出的 AES-256 金鑰，並使用 AES-GCM（搭配 128 位元標記）進行加密。
- 從輸出區域複製完整的 JSON 封包。請勿編輯、重新格式化或重新編碼任何欄位；base64url 字串、標籤與數字皆須與產生結果完全一致。
- 透過不同的管道分別傳送封包與密碼。封包本身並非機密，但密碼是，兩者絕對不可貼在同一則訊息、工單或檔案中。
- 完成傳送後，請清除頁面上的敏感內容並關閉分頁，尤其是在共用或不受信任的裝置上操作時。
解密封包與處理驗證失敗
解密與加密互為鏡像操作。選擇「解密（Decrypt）」，貼上未經修改的 JSON 封包，輸入同一組密碼，然後執行該操作。工具會先驗證標籤、數值限制、欄位語法、精確的 salt 與 IV 長度，以及最低的密文長度。在這些結構性檢查通過後，才會呼叫 Web Crypto API 進行認證與解密。
若密碼錯誤，或封包中的任何位元組遭到竄改，GCM 標記檢查便會失敗，工具會回報驗證失敗，而不會洩露部分明文。這是安全的結果：成功解密是唯一能同時證明封包與密碼皆符合原始加密的訊號。任何解密後的內容與您預期明文不符的封包，都應視為已遭到破壞。
當解密失敗時，請勿嘗試透過修剪空白、將 base64url 轉為帶填補的 base64、調換欄位，或重複使用舊的 IV 來「修復」封包。上述每一種修改都會改變標記所涵蓋的位元組，並將繼續導致驗證失敗。正確的做法是：請寄件者重新產生一份全新的封包，包含全新的 salt、IV 與密文。
AES-256-GCM 與其他常見模式的比較
不同的 AES 模式各有不同的權衡取捨，理解其差異能進一步說clarify 為何本工具選擇 GCM。下表整理了您在密碼學程式庫中最可能遇到的幾種模式。
| 模式 | 是否認證 | IV 需求 | 典型用途 |
|---|---|---|---|
| AES-256-GCM | 是，128 位元標記 | 12 位元組，每把金鑰皆須唯一 | TLS、加密儲存、可攜封包 |
| AES-256-CBC | 否，需搭配獨立 HMAC | 16 位元組，須不可預測 | 舊式磁碟與檔案格式 |
| AES-256-CTR | 否，需搭配獨立 HMAC | 12 位元組，每把金鑰皆須唯一 | 串流、磁碟加密 |
| AES-256-ECB | 否 | 無 | 僅供展示，絕對不可用於正式環境 |
GCM 在單一過程中同時完成加密與認證，並在遭到竄改時回傳明確的失敗，這也是為何本工具嚴謁的封包驗證與 GCM 標記結合後，能對每一次解密嘗試提供單一、決定性的判斷結果。
哪些項目落在密碼學邊界之外
密碼學邊界止於瀏覽器分頁。任何涉及周邊裝置、作業系統或封包目的地的環節，皆落在該邊界之外，即便密碼實作得再完美，也可能因此遭到破解。
- 瀏覽器擴充功能可以讀取頁面、輸入內容與剪貼簿。在處理敏感資料時，請停用或移除它們。
- 遭到入侵的裝置、鍵盤側錄程式、螢幕擷取功能，以及剪貼簿管理工具，都會無視密碼強度地觀察到明文與密碼。
- 共用電腦與遠端連線應被視為不信任的環境。完成操作後，請清除頁面並關閉分頁。
- 封包的目的地同樣重要。電子郵件討論串、共用文件、版本控制提交紀錄與聊天紀錄，各自帶有不同的存取控制與留存規則。
- 密碼衛生才是真正的上限。即使搭配 210,000 次 PBKDF2 迭代，一組來自密碼管理工具、長度為 20 字元的獨特密碼短語，強度仍遠高於一組重複使用的 12 字元詞組。
本工具定位於處理小型文字片段、可控的交換、展示用途與相容性實驗。它並非託管式的保險箱、企業級金鑰管理服務、加密備份系統，也無法取代經過審閱的應用層級密碼學設計。請將其用於它所設計的封套用途，並搭配封套式加密（envelope encryption）仍需要的操作紀律。