AES Encryption Online 會把整份貼上的內容、文件或腳本——也就是您需要保護的大量文字——打包成一個獨立的 JSON 套件，唯有原始密碼才能將其打開。該套件使用 AES，搭配 256 位元金鑰與 Galois/Counter 模式、重新產生的 16 位元組隨機 salt、重新產生的 12 位元組隨機初始化向量、以 210,000 次迭代進行的 PBKDF2-SHA-256 金鑰衍生，以及 128 位元 GCM 鑑別標籤。明文、密碼、衍生金鑰和解密後的輸出都不會離開當前頁面；一切皆由 Web Crypto API 完成，沒有任何資料被傳送到 Lizely。由於 AES-GCM 也會對密文進行鑑別，當密碼錯誤或套件中任何位元組遭到修改時，解密作業會拒絕回傳部分明文。
在 AES Encryption Online 中「大量」的含義
當讀者搜尋「線上大量 AES 加密」時，他們通常希望一次性保護一大段文字，而不是逐行加密。AES Encryption Online 支援這種工作流程：接受完整的明文到單一文字輸入區，並產生單一 JSON 套件作為輸出。沒有列計數器、批次清單或佇列：一個輸入、一個密碼、一個套件。該套件具有可攜性，因為 salt、IV、密文、標籤、演算法標籤與 PBKDF2 迭代次數都嵌入在 JSON 本身中，所以接收者可以在任何現代瀏覽器上將檔案交給此工具，使用密碼還原原始文字。
這種設計正是讓此工具適用於整份文件、設定檔傾印、機密程式碼片段以及小型備份的原因。您只需貼上、選擇密碼、複製套件，完全不需要管理金鑰檔、IV 檔或獨立的完整性檔——這些片段都整合進一個經過鑑別的 base64url 密文區塊中。
JSON 套件的組成結構
此套件是 JSON，而非自訂的二進位檔。每個欄位都有明確定義的角色，且工具會在解密前進行驗證。下表列出每個標籤及其承載內容，讓您能確認哪些是公開儲存、哪些必須保密。
| 欄位 | 內容 | 用途 |
|---|---|---|
| version | 整數，目前為 1 | 格式識別碼，確保未來修訂版本仍可讀取 |
| cipher | "AES-256-GCM" | 所選的鑑別式加密演算法 |
| kdf | "PBKDF2-SHA-256" | 用於密碼的金鑰衍生函式 |
| iterations | 210000 | PBKDF2 迭代次數 |
| salt | base64url，16 位元組 | 隨機 salt，非機密，混入金鑰衍生中 |
| iv | base64url，12 位元組 | 隨機初始化向量，非機密 |
| ciphertext | base64url，密文加上附加的 128 位元 GCM 標籤 | 加密位元組與鑑別標籤 |
salt 與 IV 是刻意公開的：它們的作用在於唯一性，而非保密性。密碼是唯一的機密，且工具絕不會將其嵌入套件中。ciphertext 欄位末端的 128 位元 GCM 標籤正是讓 Web Crypto API 能在不洩漏部分明文的情況下，拒絕被竄改或密碼打錯的套件。
逐步加密和解密一個大量套件
下方步驟涵蓋完整的來回流程：將一大段貼上內容密封成可攜套件，然後在另一端重新開啟它。請將 JSON 輸出視為密封的信封——保持其完整，並透過不同的管道傳送密碼。
- 開啟 AES Encryption Online 並選擇 Encrypt。
- 將完整的大量文字——一封長信、一個設定檔、一段腳本——貼入明文方塊中。
- 輸入一個至少 12 個 UTF-8 位元組的唯一密碼。強烈建議使用來自可信密碼管理工具的高熵值複雜密碼，以獲得實質的保護力。
- 執行加密。工具會使用新的隨機 salt 與 210,000 次迭代，透過 PBKDF2-SHA-256 衍生出一個不可匯出的 256 位元 AES 金鑰，然後使用新的 12 位元組 IV 與 128 位元標籤，透過 AES-GCM 進行加密。
- 完整複製所產生的 JSON 套件，與輸出完全一致。請勿重新排版、美化、刪除 base64url 字串內部的空白，或將無填充的 base64url 替換為有填充的 Base64。
- 透過一個管道（例如電子郵件附件、雲端文件、工單附件）將 JSON 套件傳送給接收者，並透過另一個獨立的加密管道（例如 Signal、當面交付、第二台裝置）傳送密碼。
- 若要還原文字，接收者開啟同一個工具，選擇 Decrypt，貼上未經修改的套件，然後輸入密碼。
- 執行解密。若密碼相符且套件的每個位元組皆完好無損，便會顯示原始大量文字。若有任何變更，工具會回報鑑別失敗，且不會洩漏套件原本包含的內容。
為何相同的大量輸入每次執行會產生不同的輸出
如果您使用相同密碼對同一份長文件加密兩次，產生的兩個 JSON 套件看起來完全不同。這是刻意的設計。AES Encryption Online 每次執行都會產生新的 16 位元組 salt 與 12 位元組 IV，然後將 salt 混入 PBKDF2 中、將 IV 混入 AES-GCM 中。這會帶來兩個結果。第一，即使明文完全相同，密文位元組也會不同，這能防止被動觀察者透過確定性輸出辨識出內容相等。第二，salt 儲存在套件中，因此解密時能重新計算出相同的金鑰——如此一來，套件便能在不依賴任何外部狀態的情況下保持獨立自足。
這項設計也意味著您絕不該透過編輯套件來重複使用舊的 IV 或 salt。AES-GCM 要求 IV 對於給定金鑰必須是唯一的，而工具會透過每次產生新的隨機值（而非讓使用者貼上）來保證這種唯一性。隨機值之所以公開儲存，是因為其作用在於唯一性與金鑰衍生，而非保密性。
哪些內容停留在密碼學邊界之內
理解此工具的一個實用方式，是將密碼學本身與其所在的裝置區分開來。密碼學邊界涵蓋 AES-256-GCM 轉換、PBKDF2-SHA-256 衍生、128 位元鑑別標籤、version 1 的 JSON 格式，以及 salt、IV 與密文加標籤的 base64url 編碼。該邊界會根據 W3C Web Cryptography Level 2 規格，對照 NIST AES-GCM 測試向量——包括空明文鑑別案例與完整零區塊加密案例——以及 RFC 4648 base64url 測試案例進行驗證。這些檢驗證明了已定義的轉換與套件不變式；它們並非認證瀏覽器、裝置、密碼選擇或更廣泛的工作流程。
此工具本身的產品契約對此立場相當明確：瀏覽器擴充功能、剪貼簿管理工具、截圖工具、共用電腦，以及套件所貼上的目的地，皆不在密碼學邊界之內。當周遭裝置不受信任時，請清除敏感內容並關閉分頁。此頁面適用於小型文字片段、展示、受控交換與相容性實驗。它並非受管理的儲存庫、企業金鑰管理服務、加密備份系統，也無法取代經過審核的應用層密碼學設計。
大量貼上的實際限制
兩項限制決定了此工具中「大量」套件的大小。第一項是密碼規則：介面要求至少 12 個 UTF-8 位元組，並接受更長的複雜密碼。不允許使用單位元組密碼進行大量加密，因為短密碼會從根本上削弱 PBKDF2 衍生的效果，無論執行多少次迭代都無補於事。第二項限制是 JSON 格式本身：套件必須使用無填充的 base64url 欄位、精確 16 位元組的 salt 長度、精確 12 位元組的 IV 長度，以及長度足以容納 128 位元 GCM 標籤的密文。在 Web Crypto 進行鑑別之前，若移除任何欄位、將 base64url 字串內部的空白標準化，或在應使用 base64url 之處插入有填充的 Base64，都會導致解密因驗證錯誤而失敗。
對於非常大的貼上內容，還需考量剪貼簿與目的地。瀏覽器剪貼簿的大小上限、電子郵件內文長度限制、工單附件配額，以及接收端的任何日誌中介軟體，都可能截斷或分割套件。若您要密封的內容超出舒適的貼上大小，請將輸入分割成少數幾個具名套件，而非將其串連起來——每個套件都是獨立的，可以單獨開啟。
挑選能在大量規模下站得住腳的密碼
PBKDF2-SHA-256 搭配 210,000 次迭代能提高猜測密碼的成本，但無法挽救過短、重複使用、已外洩或可預測的複雜密碼。對於一份您可能數月不再開啟、或是會交給同事的大量文件，請從您信任的密碼產生器中產生全新的高熵值複雜密碼，將其儲存於密碼管理工具中，並且絕不將其貼入與套件相同的傳輸管道。套件所公開的 salt 與 IV 並不會削弱密碼；它們只是讓金鑰衍生與 AES-GCM nonce 具備唯一性。
最後，請在傳送者與接收者之間保持整個套件原封不動。將 JSON 視為不透明的信封：不要標準化換行格式、不要將 base64url 轉換為標準 Base64，也不要刪除任何欄位。AES-GCM 鑑別仰賴完全相同的位元組存在，因此即使是單一字元的外觀調整，也可能讓可運作的套件變成無法還原原始明文的鑑別失敗。
如需深入瞭解，請參閱大量 ASCII 碼轉換器：將長貼上內容編碼為十進位。
如需深入瞭解，請參閱Base64 轉 Hex 大量處理：在本機處理大型輸入。