重複金鑰 XOR 加密是一種可逆的混淆方式，並非真正的安全加密，因為任何取得金鑰的人都能立即讀取訊息內容，且輸出結果不帶任何完整性檢驗。重複金鑰 XOR 轉換會使用位元互斥或運算（bitwise exclusive OR）將每個明文字元組與對應的金鑰字元組結合，當金鑰用盡時便從頭重新開始，因此相同的金鑰搭配相同的 UTF-8 明文，必定會產生相同的密文字元組。這種對稱性同時也是其核心弱點：使用同一把金鑰將同一運算執行兩次，便會還原成原始文字，這代表攻擊者能對訊息做的任何攪亂動作，只要金鑰一外洩，收件者就能立刻還原。整個流程中沒有 nonce、沒有 salt、沒有認證標籤，也沒有耗時的密碼延伸步驟，因此一旦密碼外洩或使用容易猜測的短詞，結果就會徹底被破解。XOR Encryption Online 工具對此坦誠以告：它嚴格遵循重複金鑰的慣例，同時提供密文字元組的十六進位與 Base64 兩種表示方式，全程在瀏覽器內執行，無需上傳，並將輸出視為可逆的解謎遊戲，而非機密性的保證。
重複金鑰 XOR 實際上計算了什麼
重複金鑰 XOR 是教科書中最簡單的對稱轉換：取明文的第一個 UTF-8 字元組，與金鑰的第一個 UTF-8 字元組透過 MDN 位元 XOR 參考文件 中所定義的位元互斥或運算加以結合，寫下結果後再處理下一個字元組。當金鑰用盡的瞬間，會從第一個字元組重新開始，因此長度為 k 的金鑰會以 k 為週期在整段訊息中重複。以數學表示即 plaintextBytes[i] XOR keyBytes[i mod keyLength]，又因為 XOR 是自身的反運算，再次套用相同的運算式便會還原回原始字元組。
慣例相當關鍵，這正是需要獨立工具存在的全部原因。明文與金鑰在進行任何位元運算之前，都會先透過瀏覽器標準的 TextEncoder 進行編碼，因此視覺上相同的字元必定會序列化為相同的字元組。一個 Unicode 表情符號（例如 🌍）在內部佔用四個 UTF-8 字元組，因此會消耗四個金鑰位置，雖然它在畫面上看起來只是一個字元。將字元組序列視為事實的來源，能確保所有採用現代 UTF-8 編碼器的實作之間，結果都能彼此重現。
單一位元組的運算範例
為了不使用任何填補或格式化技巧，便能清楚看見運算過程，以下以 ASCII 字元 A 作為明文、K 作為金鑰進行加密：
- A 在 UTF-8 中是單一位元組 0x41，二進位為 0100 0001。
- K 在 UTF-8 中是單一位元組 0x4B，二進位為 0100 1011。
- 位元 XOR 逐欄對齊後結果為：0100 0001 XOR 0100 1011 等於 0000 1010，也就是 0x0A，十進位的 10。
因此這個單一位元組所對應的密文就是 0x0A。若要解密，收件者執行 0x0A XOR 0x4B，便能還原出 0100 0001，也就是 A。相同的算術無論正向或反向都能運作，而這正是只要金鑰一經洩漏，XOR 便能輕易被還原的關鍵特性。真實的訊息只是沿著同一條逐位元組的管線流動；差別只在於輸入長度與金鑰長度變長了。
為何 XOR 無法作為機密性加密原語
現代加密必須解決三個問題：確保訊息機密性、偵測任何竄改行為，以及將人類易記的密碼轉換為能抵抗暴力破解的金鑰。重複金鑰 XOR 一個也沒有解決，而且這些弱點並不隱晦。
首先，重複會暴露規律。一旦攻擊者得知金鑰長度，密文便會被切割為 k 條彼此獨立的單一位元組 XOR 串流，而每一條串流都會敗給針對英文、JSON、原始碼或明文所用語言的頻率分析。密碼學家稱這種手法為「crib dragging」，在普通筆記型電腦上，僅需幾分鐘便能破解以 KB 計的訊息。
其次，缺乏完整性與真實性驗證。任何持有密文的人都可以在選定位置翻轉位元，而收件者完全無法察覺，因為該工具從未輸出 MAC、認證標籤或任何會隨位元變動而改變的摘要。偽造行為既無聲響又無成本，這正是 XOR 從不出現在需要信任訊息內容的通訊協定中的原因。
第三，金鑰欄位被視為純文字處理，而非衍生後的祕密。整個流程中沒有類似 Argon2id 或 PBKDF2 的慢速密碼延伸函式、沒有 salt、沒有 nonce，也沒有版本欄位。字典中的一個四字單字，其熵值遠比一般讀者預期的更接近零位元；而更長的金鑰只有在其本身為不可猜測的隨機位元組、且無人能在背後偷看時，才能發揮作用。
基於上述理由，XOR Encryption Online 頁面將其輸出定位為用於教學、互通性檢查與 CTF 搶旗賽的可逆混淆工具，並警告使用者切勿將其用於密碼、個人資料、付款資訊、私鑰，或任何必須保持機密或不可竄改的資料。
十六進位 vs Base64：工具實際輸出的內容
XOR 運算所產生的密文字元組始終相同，差別僅在於用來顯示的編碼方式。因此該工具在加密模式下會同時顯示兩種表示法，並在解密模式下要求使用者擇一使用。若在解密端選錯表示法，會直接產生解析錯誤，絕不會悄悄回傳錯誤結果。
| 面向 | 十六進位輸出 | Base64 輸出 |
|---|---|---|
| 符號字母表 | 僅使用 0-9 的數字與小寫 a-f | A-Z、a-z、0-9、+、/ |
| n 個位元組的長度 | 恰好 2n 個字元 | 約 4 × ceil(n/3) 個字元 |
| 是否填補至固定倍數 | 一定會；每個位元組對應兩位數 | 可能附加零個、一個或兩個 = 字元 |
| 輸入時是否容許空白字元 | 予以忽略 | 予以忽略 |
| 最適合的用途 | 除錯與位元組檢查 | 透過電子郵件或聊天欄位傳遞 |
| 是否會改變底層密文字元組 | 否 | 否 |
在加密模式下切換輸出格式僅為外觀上的差異。雙方使用者仍必須對金鑰文字達成共識，包含大小寫及所有空格，否則還原出來的明文將與原始訊息不符。
使用 XOR 工具加密與解密文字
瀏覽器中的操作流程刻意設計得相當簡短。請開啟 XOR Encryption Online，然後依照下列步驟傳送收件者能夠還原的訊息。
- 於表單頂端選擇加密模式，在訊息欄位中輸入或貼上明文，並如實輸入金鑰，務必與收件者將輸入的內容一致。金鑰會以 UTF-8 文字形式處理，因此每個可見字元皆對應一個或多個位元組。頁面會拒絕空白的明文或空白的金鑰，且每個欄位的上限為 100,000 位元組。
- 執行加密動作。整個轉換會在您的瀏覽器中使用 TextEncoder 搭配純 JavaScript XOR 迴圈執行，因此明文、金鑰與結果都保留在本機，絕不會上傳。
- 複製密文的十六進位或 Base64 表示法。兩者編碼的是相同的位元組，請依收件者工具所能接收的格式擇一使用。
- 透過另一個獨立管道告知收件者您所傳送的表示法，以及完整的金鑰文字，包含大小寫與所有空格。
- 在接收端，選擇解密模式，挑選對應的表示法，將密文貼入輸入欄，並輸入完全相同的金鑰。
- 若解密時未通過嚴格的 UTF-8 檢查，頁面會回報錯誤，而非以替代字元悄悄帶過。請逐字比對金鑰，並確認傳輸過程未對密文進行刪減、重排或重寫。
能夠還原出明文並不代表明文內容正確，因此該工具也會提醒使用者，必須透過獨立管道再次確認輸出內容無誤，才能據以採取任何實際行動。
重複金鑰 XOR 適用與不適用的情境
| 情境 | 是否使用 XOR 瀏覽器工具 | 理由 |
|---|---|---|
| 課堂示範 XOR 如何轉換位元組 | 是 | 直接處理真實位元組，無需任何設定 |
| 使用已公開金鑰的 CTF 解題交流 | 是 | 符合可逆謎題格式的設計初衷 |
| 兩種編碼之間的互通性檢查 | 是 | 可依需求同時產生十六進位與 Base64 |
| 儲存密碼、付款資訊或私鑰 | 絕對不行 | 無機密性、無完整性、無密碼延伸機制 |
| 任何需要偵測密文竄改的用途 | 絕對不行 | 沒有 MAC 或認證標籤 |
| 任何受資料保護法規規範的用途 | 絕對不行 | 無法滿足任何機密性要求 |
這項警告是產品內建的一部分：熟悉的「加密」標籤並不等於保護的保證，而該頁面也拒絕暗示其他結論。事先了解其限制，正是使用這項工具的核心目的。
從 XOR 邁向真正的認證加密
當機密性與完整性同樣重要時，下一步應採用 AES-256-GCM 或 ChaCha20-Poly1305 等認證加密機制，並搭配真正的金鑰衍生函式。金鑰絕不會以密碼形式直接輸入；而是透過 Argon2id 或 PBKDF2（並附上公布的迭代次數）對密碼進行延伸，再將衍生出的位元組連同一個隨機 nonce 一起餵入加密器，而該 nonce 會與密文一同儲存。由於認證機制已內建於模式之中，密文或 nonce 中任何位元的翻轉，都會導致解密端直接失敗。
同一個網站亦提供 AES Encryption Online 工具，可將 AES-256-GCM 的輸出包裝成一個可攜的 JSON 套件，其中包含 salt 與 nonce。關於該套件格式的深入說明，可參考 AES-256 Encryption: Inside an Authenticated GCM Package 指南；另外還有獨立的 password strength checker 工具，可在密碼送入金鑰衍生函式之前，先檢視所選詞組是否符合實務上的長度與不可預測性門檻。
XOR 仍是一項有用的教學原語，也正是這項工具存在的原因，但將其視為機密性工具屬於類別上的錯誤，而非設定上的瑕疵。
延伸閱讀：AES Encryption Online Alternative Built on AES-256-GCM。