AES Encryption Online 可在 Android 上透過任何現代瀏覽器分頁執行，完全在手機上套用 AES-256-GCM 並以 PBKDF2-SHA-256 進行金鑰衍生，無需安裝應用程式，也無需上傳至任何伺服器。在 Chrome、Firefox 或 Edge 中開啟頁面，切換到 Encrypt，輸入明文以及一個至少 12 個 UTF-8 位元組的密碼，頁面就會產生一個自包含的 JSON 套件，可以複製、儲存，或透過任何 Android 分享應用程式傳送。解密時使用同一組密碼對應同一個套件；若密碼錯誤或套件遭到編輯，AES-GCM 的認證標籤會讓操作失敗，而不會洩漏任何部分明文。每次執行都會產生全新的 16 位元組 salt 與全新的 12 位元組 IV，因此刻意對相同文字加密兩次會得到兩個不同的套件。明文、密碼、衍生的金鑰以及解密結果都不會離開目前分頁；所有運作皆在裝置上的 Web Crypto API 內建立並消化。

aes encryption online on android
Android 上的 AES Encryption Online：瀏覽器操作流程

為何瀏覽器工具適合你口袋裡的手機

想要加密一小段文字的 Android 使用者有兩條實際可行的路徑：從 Play 商店安裝專用的 AES 應用程式，或開啟瀏覽器分頁執行本機的 Web Crypto 實作。安裝路徑會要求儲存權限、接受背景更新，並把使用者綁定在某家廠商的金鑰處理慣例上。瀏覽器路徑則完全不需要這些。頁面載入一次後，加密工作就會在頁面的 JavaScript 環境中使用 Web Crypto 進行，因此裝置不需要為了加密五十個字的會議筆記而多安裝一個二進位檔。對於每週只需要使用幾次 AES 加密的人來說，這種取捨偏向瀏覽器。

瀏覽器選項適合行動裝置的另一個原因：它能跨裝置跟著使用者走。同一個 JSON 套件可以在 Android 的 Chrome、iOS 的 Safari、Linux 筆電的 Firefox 或 Windows 的 Edge 中開啟。只要接收端的瀏覽器實作了 Web Cryptography Level 2 規格，且套件本身是依照文件中記載的 AES-256-GCM 參數所產生，該格式就能流通。然而 JSON 欄位配置並非通用標準，因此若第三方工具沒有重現相同的 UTF-8 處理、PBKDF2 參數、AES-GCM 標籤位置、base64url 編碼與 JSON 欄位，就無法解密。這對個人用途的交換沒問題，但在承諾與他人技術棧相容之前，請先銘記在心。

情境瀏覽器 AES 工具Android 原生 AES 應用程式
在借用來的手機上進行快速的一次性加密無需安裝，除分頁外不會留下任何痕跡新增永久的應用程式圖示與權限
重複處理非常大的檔案適合短文字片段，非受管理的保險庫更合適，內建檔案選擇器與裝置端儲存
在手機與筆電之間共用相同格式同一 JSON 套件可於任何現代瀏覽器運作通常鎖定在該應用程式的匯出格式
嚴格的企業金鑰管理並非為保險庫、託管或稽核軌跡所設計部分應用程式可與 MDM 與金鑰儲存庫整合
網路受限環境載入一次後，無需再連網即可運作相同 — 一旦安裝，兩者皆可離線運作

在 Android 瀏覽器中開啟工具

在 Android 手機上，工作流程從網址列開始，而非 Play 商店。開啟 Chrome（或任何公開 Web Crypto API 的瀏覽器）並直接載入 AES Encryption Online 頁面。頁面只會渲染單一分頁，內含兩種模式、兩個文字欄位與密碼框；除此之外無需載入任何其他內容。從瀏覽器選單將頁面加入主畫面，即可獲得一個一鍵點擊的圖示，以獨立框架開啟工具，對於每週需執行相同加密任務數次的情況特別方便。

行動鍵盤、自動完成與剪貼簿紀錄都會以桌面使用者不見得會想到的方式與密碼欄位互動。Gboard 的自動完成可能會建議儲存密碼；當該建議對應的是由真正的密碼管理工具管理的唯一通行密碼時沒問題，但若該建議是手機自動儲存、最終同步到 Google 自動填入雲端的憑證時，就不太理想。在加密前請確認密碼輸入正確 — 行動鍵盤經常自動校正或替換外觀相似的字元，單一字元錯誤就會在接收端導致認證失敗。請使用具備生物辨識解鎖功能的密碼管理工具，這樣就不必在玻璃螢幕上手動重新輸入通行密碼。

在 Android 上加密一段文字片段

頁面開啟後，加密只需三個簡短步驟。依序的具體動作為：

  1. 點擊頁面頂端的 Encrypt，讓表單進入加密模式，然後在第一個文字欄位中輸入要保護的明文。
  2. 在密碼欄位中輸入長度至少 12 個 UTF-8 位元組的唯一密碼，然後執行加密。頁面會透過 PBKDF2-SHA-256 以 210,000 次迭代衍生出 256 位元的 AES 金鑰，並為此次執行產生全新的 16 位元組 salt 與全新的 12 位元組 IV。
  3. 從輸出區域複製產生的 JSON 套件。請原封不動地保留套件 — 每個欄位、每個 base64url 字元、每個帶引號的標籤都必須維持原樣 — 並透過不同的管道將密碼傳送給接收端。

由於每次執行都會重新產生 salt 與 IV，即使對相同的明文與密碼輸入兩次，輸出的 JSON 也會改變。這是預期且刻意的設計，正如 NIST SP 800-38D 所記載：AES-GCM 的初始化向量在給定金鑰下必須唯一，而隨機產生是保證此特性最簡單的方式。去除重複性也是防止攻擊者比對兩段密文以確認其隱藏相同訊息的關鍵。

明文、密碼、衍生的金鑰以及最終的 JSON 都不會離開分頁。它們不會被提交給 Lizely、不會進入雲端紀錄、也不會被自動完成收錄。只有在使用者明確複製 JSON 並貼到另一個應用程式時，內容才會被分享 — 這個界線由使用者自行決定，而 Android 的分享選單讓你可以輕鬆地把套件交給 Signal、Gmail、Drive 或任何已安裝的目標應用程式。

將 JSON 套件解密回明文

在接收端的手機上，工作流程與寄送端步驟相對應，只需切換模式。

  1. 點擊 Decrypt，讓表單進入解密模式。
  2. 將原封不動的 JSON 套件貼入套件欄位，並將對應的密碼貼入密碼欄位。
  3. 執行解密。若密碼正確且位元組完整，明文就會出現在結果欄位中。

若密碼錯誤，或套件中的任何位元組遭到變更，AES-GCM 的 128 位元認證標籤會使檢查失敗，頁面會回報認證錯誤，而不會洩漏部分輸出。這是核心安全特性：遭竄改或輸入錯誤的密碼不會慢慢洩漏訊息。驗證流程會先檢查 JSON 標籤、數值限制、欄位語法、精確的 16 位元組 salt 長度、精確的 12 位元組 IV 長度以及最短密文長度，只有通過這些檢查後，Web Crypto 才會嘗試執行認證操作。管線中任何階段的失敗都會回報為驗證錯誤，而非成功解密。

讓套件保持安全的 Android 使用習慣

瀏覽器加密是本機的，但包圍它的裝置並非如此。以下幾個 Android 專屬的習慣可降低交換的套件外洩的機會：

  • 將密碼與套件視為兩個獨立的產物。透過一個應用程式（電子郵件、Signal、檔案分享）傳送 JSON，並透過另一個應用程式傳送密碼。對兩者使用同一管道是最常見的失敗模式。
  • 在貼上 JSON 或解密結果後清除剪貼簿。Android 13 及以後版本會在短暫時間後自動清除複製的內容，但較舊版本則會無限期保留。
  • 在處理敏感內容前停用螢幕錄製與截圖輔助工具。部分 Android 鍵盤與輔助功能工具能在背景擷取螢幕。
  • 使用由密碼管理工具產生的高熵唯一密碼。PBKDF2 會提高猜測成本，但沒有任何衍生函數能挽救過短、重複使用或已外洩的密碼。
  • 在交換完成後關閉瀏覽器分頁與接收結果的應用程式。解密後的明文會停留在頁面的 DOM 中，直到分頁關閉或重新整理。

若裝置是共用的、借來的，或處於無人看管狀態，這些習慣的重要性就超過加密演算法的選擇。AES-256-GCM 是強大的原語，但它無法保護內容免於剪貼簿管理工具、受感染的瀏覽器擴充套件，或在解密後所進行的螢幕擷取。

JSON 套件內部：標準元件、工具專屬配置

JSON 套件會宣告自身的格式。版本標籤固定為 1；加密演算法標籤為 AES-256-GCM；金鑰衍生標籤為 PBKDF2-SHA-256；迭代次數為 210,000。salt、IV 與密文皆以 base64url 字串儲存 — 依據 RFC 4648，採用不含填補字元的 URL 安全 Base64 字元集 — 因此該檔案可嵌入另一個 JSON 文件中，或透過會破壞 + 與 / 字元的協定傳送。

由於編碼不含填補，每個 base64url 欄位的磁碟長度由其所承載的原始位元組數決定。一個計算範例：16 個原始 salt 位元組 = 16 × 8 = 128 位元，在不含填補的 base64url 中以每字元 6 位元計算，salt 欄位恰為 ⌈128 / 6⌉ = ⌈21.33⌉ = 22 個字元。12 位元組的 IV 為 12 × 8 = 96 位元，編碼後為 ⌈96 / 6⌉ = 16 個字元。密文長度會隨輸入增長，並在結尾包含 16 位元組的 GCM 認證標籤，因此 30 字元的明文會產生 46 位元組的密文區塊 — 30 位元組的加密內容加上 16 位元組的標籤 — 編碼後為 ⌈368 / 6⌉ = 62 個字元。這三個固定或可預測的長度，在手動檢視套件時是相當實用的健全性檢查指標。

密碼學元件遵循標準化規格，但外層的 JSON 欄位配置為本工具專屬，因此其他系統只有在重現相同的 UTF-8 處理、PBKDF2 參數、AES-GCM 標籤位置、base64url 編碼與 JSON 欄位時，才能互通。編輯套件 — 例如在預期 base64url 之處插入傳統含填補的 Base64、調換 salt 與 IV 欄位、或將空白字元標準化 — 都會導致下次解密嘗試時驗證失敗。請將套件視為不透明資料，以文字形式複製，並將密碼保持在頻外（out of band）。

如需更深入的了解，請參閱 在 Android 上無需安裝應用程式即可解碼 Base58。