AES 解密使用 Lizely 工具完全在瀏覽器中透過 Web Crypto API 運作,需要加密時所使用的確切密碼,且僅在 128 位元鑑別標籤驗證通過該封包時,才會回傳原始明文。如果 JSON 封包的任何位元組發生變動,或密碼有任何單一位元組的差異,工具會拒絕輸入並顯示鑑別失敗,且不會洩漏明文的任何部分。輸出內容絕不會從頁面外傳,密碼也絕不會被寫入封包中,Lizely 也沒有任何伺服器端的這兩項資料記錄,因此解密既有封包的唯一方式,就是將封包與密碼帶到同一個瀏覽器工作階段中。
本工具中「AES Decrypt Online」的含義
搜尋「AES decrypt online」通常代表您已擁有 AES 加密封包,並希望以快速方式還原原始文字。AES Encryption Online 正好能做到這點,但有一項重要限制:輸入內容並非原始的 Base64 密文,而是結構化的 JSON 封包。該封包內嵌解密所需的所有資訊,包括 AES 模式標�、PBKDF2 迭代次數、隨機 salt、隨機初始化向量,以及已鑑別的密文,並附帶 128 位元 GCM 鑑別標籤。您只需貼上封包、輸入密碼,即在本地執行解密;若 Web Crypto 驗證通過該封包與標籤,便可直接在頁面上看到原始明文,並能以文字形式將其複製出來。
解密路徑正是加密路徑的完全反向。PBKDF2-SHA-256 以 210,000 次迭代將 UTF-8 密碼與儲存的 salt 轉換為不可匯出的 256 位元 AES 金鑰,AES-GCM 使用儲存的 IV 與該金�驗證標籤,僅在驗證通過後才釋出解密位元組。由於每個步驟都在瀏覽器中進行,您可在任何現代版的 Chromium、Firefox 或 Safari 環境中使用此頁面,無需安裝軟體、註冊帳號,或將密碼交由遠端服務處理。
對 AES 封包執行解密
請依照以下具體步驟,使用 AES Encryption Online 的解密模式,對既有的 AES-256-GCM JSON 封包進行解密。
- 將工具切換至解密模式,將完整的 JSON 封包原樣貼入封包欄位,不得移除任何尾端空白,亦不得編輯任何欄位。
- 於密碼欄位中輸入加密當時所使用的密碼。最小長度為 12 個 UTF-8 位元組,但密碼必須完全位元組一致,因此大小寫、空格及不可見的 Unicode 字元皆會造成差異。
- 執行解密。工具會在呼叫 Web Crypto 之前,先驗證 JSON 標�、數值限制、欄位語法、salt 必須為確切 16 位元組長度、IV 必須為確切 12 位元組長度,以及最低密文長度。
- 讀取結果。成功時,原始明文會顯示於輸出區,可直接以文字形式複製。失敗時,工具會回報鑑別錯誤,且不會顯示任何部分明文。
- 清除密碼與輸出內容,接著在確認裝置並非完全可信時,於使用完畢後關閉分頁。
AES-256-GCM JSON 封包結構剖析
JSON 封包是一個自我描述的容器,內含瀏覽器重建 AES 金鑰並驗證標籤所需的每一項數值。了解每個欄位的用途,有助於更輕鬆地診斷解密失敗。標籤區分大小寫,且欄位語法嚴格;下表摘要說明每個欄位的內容及其在工具中的用途。
| 欄位 | 編碼 | 解密期間的用途 |
|---|---|---|
| version | integer | 確認封包佈局為 v1。任何非 1 的值都會被拒絕。 |
| cipher | string "AES-256-GCM" | 宣告模式與金鑰長度,以便瀏覽器選用正確的 Web Crypto 演算法。 |
| kdf | string "PBKDF2-SHA-256" | 指示瀏覽器使用 PBKDF2-HMAC-SHA-256 衍生 AES 金鑰。 |
| iterations | integer | 金鑰衍生期間使用的迭代次數。本工具目前使用 210,000。 |
| salt | base64url | 16 位元組的隨機 salt。以明文儲存,因其用途在於唯一性而非機密性。 |
| iv | base64url | 12 位元組的隨機初始化向量。每把金鑰必須使用唯一值;本工具在每次加密時都會產生全新的值。 |
| ciphertext | base64url | 已鑑別的密文,包含 Web Crypto 回傳的 128 位元 GCM 標籤。 |
此封包佈局為本工具專用。其所使用的密碼學原語是標準化的,但外層的 JSON 信封並非通用檔案格式,因此其他系統只有在重現相同的 UTF-8 處理、PBKDF2 參數、AES-GCM 標籤位置、base64url 編碼及欄位名稱時,才能與之互通。解密時請保持整個封包完全不變;移除欄位、以錯誤方式正規化文字,或在需要 base64url 的位置插入傳統的帶等號填充 Base64,都會在 Web Crypto 被呼叫之前導致驗證失敗。
為何鑑別失敗不會顯示部分明文
AES-GCM 將加密與鑑別結合在一起。當工具要求 Web Crypto 執行解密時,瀏覽器會先根據密文、IV 與衍生金�重新計算鑑別標籤,並與封包中所儲存的標籤進行比對。只有在兩個標籤逐位元組相符時,瀏覽器才會釋出解密後的明文。若密碼錯誤,衍生金鑰便會改變,重新計算的標籤將不再相符,解密作業會在任何明文位元組回傳之前中止。
若有人編輯封包,同樣的情況也會發生。重複使用舊的 IV 搭配相同密文、修剪 JSON 解析器原本未處理的空白字元,或以標準 Base64 取代 base64url,皆會導致驗證或鑑別失敗。嚴格的前置驗證步驟會在 Web Crypto 被呼叫之前,以清楚的錯誤訊息拒絕格式錯誤的封包;而結構有效但遭到竄改的封包,則會在 GCM 標籤檢查階段失敗。在這兩種情況下,工具都會回報鑑別失敗,且不會顯示任何部分明文——這正是已鑑別加密演算法應有的行為,也是該失敗訊息無法透露密碼究竟有多接近正確值的原因。
密碼要求與常見的解密失敗
介面要求密碼至少為 12 個 UTF-8 位元組,並接受更長的 passphrase。使用 210,000 次迭代的 PBKDF2 會提高猜測密碼的成本,但無法挽救過短、重複使用、外洩或可預測的密碼。解密成功與否,取決於密碼是否與加密當時的密碼完全位元組一致;即使只有一個錯誤字元、不同的 Unicode 正規化形式,或含有隱藏尾端空白的自動填入密碼,都會在封包本身完全正常的情況下,仍造成鑑別失敗。由於加密與解密皆在本地端執行,密碼從未上傳或儲存,且背後也沒有任何還原或託管服務,因此 Lizely 無法還原遺失的密碼。
若解密持續失敗,請在認定封包已損毀之前,先逐項檢視以下簡短清單:
- 確認封包確實來自此工具,且未經編輯、未以不同格式美化排版,亦未被文字編輯器重新儲存而剝除尾端字元。
- 手動重新輸入密碼,不要依賴剪貼簿管理工具、瀏覽器自動填入或密碼管理工具,以免其夾帶不可見的位元組。
- 確認 JSON 中的欄位標籤與上表所列完全一致;工具會拒絕未知欄位,以及非 1 的版本編號。
- 確認 base64url 欄位僅包含未填充的 base64url 字元。若加上「=」填充或改用標準 Base64,會在 Web Crypto 執行之前即導致驗證失敗。
- 確認接收端裝置未受剪貼簿管理工具、瀏覽器擴充功能或螢幕擷取影響,以免在解密成功後洩漏明文。
AES Decryption Online 適用的情境
本工具適用於小型文字片段、示範用途、兩個已透過外部管道共用密碼的雙方進行受控交換,以及需要檢視瀏覽器所產生之 JSON 佈局的相容性實驗。它也是驗證所收到封包的快速方式:貼上封包、輸入密碼,接著要嘛看見原始文字,要嘛得到清楚的鑑別錯誤。內容不會離開頁面,因此在裝置本身可信,且周邊工作流程將密碼保存在獨立的安全管道(例如密碼管理工具或端對端加密訊息)中的情況下,本工具是合適的選擇。
它並非託管式的保險庫、企業金鑰管理服務、加密備份系統,也無法取代經過審�的應用程式層級密碼學設計。瀏覽器擴充功能、遭到入侵的裝置、剪貼簿管理工具、螢幕擷取、共用電腦,以及您貼上解密文字的目的地,皆處於密碼學邊界之外。請透過可信的密碼管理工具產生強且唯一的 passphrase,以獲得有意義的保護,在將其用於任何敏感用途前檢視其長度與明顯的規律,接著在周邊裝置不受信任時,清除輸出並關閉分頁。實作已對照 NIST AES-GCM 測試向量進行驗證,包含空明文鑑別案例與全零區塊加密案例;base64url 測試案例遵循 RFC 4648,而 AES-GCM、PBKDF2 與金�衍生行為則遵循 W3C Web Cryptography 規範。
相關�讀:如何使用 mod 26 反矩陣解密 2x2 Hill Cipher。
相關閱讀:如何在本地端為 1Password 產生密碼。