用全詞實現對稱加密算法
設想
我對加密文本有一些獨特的要求：
- 對稱加密；
- 加密文本將是有效文本（這意味著人類可以閱讀它，而不僅僅是“胡言亂語”）；
- 我不能不時更換密鑰（這意味著沒有臨時\一次性密鑰算法）；
- 每個單詞必須始終加密為同一個單詞（並且僅加密為一個單詞）。
這些需求對於支持以下案例很重要：
- 第三方將獲得加密文本並能夠對其進行索引以進行搜尋（有效的索引需要基本形態，這就是為什麼需要 2 很重要）；
- 當有人向該第三方發送一個加密詞時，它將能夠找到與這些詞相關聯的文本（這就是為什麼需要 3 和 4 很重要）。
但我在系統中也有一些靈活性：
- 我總是可以在字典中添加更多單詞（如果需要在加密/解密過程中）；
- 發送者和接收者都可以訪問這個字典（總是同步的）。
範例方案
所以基本上我可以使用某種字典並映射單詞並替換加密單詞中的每個單詞（如凱撒密碼，但用於單詞）。
每次遇到一個單詞時，我都可以將其作為原始單詞和加密單詞添加到字典中。
例如：
- 詞：“我” 加密詞：“貓”
- 詞：“愛” 加密詞：“狗”
- 詞：“你” 加密詞：“家”
現在文本“我愛你”將被加密為“貓狗之家”。這符合我的所有需求。但您可能知道，這是一個非常周密的加密。
為了使它更強大，我正在考慮隨機插入我知道是假的單詞（沒有映射到真實單詞），這（也許？）阻止了對語言（常用詞等）的統計分析。
例如： - 加密詞：“男孩”是假的。- 加密詞：“Test’s”是假的。
現在文本“I Love You”將被加密為“Cat Test’s Boy Dog Test’s Home Boy”。這符合我的所有需求。但我相信這仍然很弱，所以我正在尋找更好的東西。
對稱密碼
我已經閱讀了 Blowfish、Twofish 和 AES-256 等對稱加密算法，根據我的（有限）理解，它們都是用一個字節替換另一個字節的算法，它們認為是強加密方法。
是否可以實現對稱密碼，但不是對字節進行操作，而是對字進行操作？
筆記
經過進一步研究，我了解到這個問題更具誤導性而不是幫助。
該問題詢問加密但指向混淆 - 一些答案可能也是如此。
我相信菜鳥（像我一樣）會比從中獲得任何東西更容易分心和誤導。
我認為，你最好的選擇是反其道而行之。
- 使用經過驗證的算法安全地加密。
- 使加密文本人類可讀。
例如：AES-256 使用某些密鑰對“Squeamish Ossifrage”進行編碼。比如說，得到 512 位的絕對亂碼。即 64 個字節，每個 8 位；每個字節可以有 256 個值之一。
獲取 256 個單詞的字典（可能是短單詞？）。讀取 64 個字節，並將每個值轉換為適當的單詞，給你一個 64 個單詞的“句子”：
Cat Hue Way Ten One Bat Bob Nod Ben Elk Joe Sex Van Eke ...要解碼，讀入每個單詞，然後在字典中查找。這是第 42 個字 ==> 將其讀取為值為 42 的字節。將所有字節一個接一個地放回加密文本，AES-256 對其進行解碼，鮑勃是你的叔叔。
這樣，大約 100 字節的文本變成了 60 字節的加密二進制程式碼，而那些變成了 240 字節的重新人性化程式碼（每個單詞是 3 個字母加一個空格）。或者 180 字節，如果你用駝峰法把它：BobTenHueNitPinZoo…。你有一個大約 1:2 或 1:3 的整體擴展，這是相當合理的。
核心是 AES-256。沒有人想弄亂 AES :-)
詞變成詞
您希望“Cat”始終被加密為“Dog”。這提出了兩個問題。首先，您要麼需要指定所有可能的輸入詞，要麼接受某些詞會變得亂碼；可能是明顯的胡言亂語（有算法），但仍然是胡言亂語。
例如，您可以使用包含簡單加擾算法的字典。當您在明文中找到單詞 #1138 時，加密 1138 - 如果字典的大小是 2 的整數冪，例如 65536 個單詞，則可以通過位交換來完成 - 以便它成為同一字典中的另一個數字，比如說 31794。單詞 1138（“馬”）變成了單詞 31794（“主食”）。
如果一個詞不在字典裡怎麼辦？然後，您需要將其加密為一個肯定不在字典中的單詞（否則您將無法解密它）。所以貓變成了狗，馬變成了主食，電池變成了正確的……而rumplestiltskin變成了 xyzbatelkjoesexvanekewayhuejimsixnoddandinsupfoxfenjoeputits - 其中xyz前綴警告解碼器接下來是加密序列。
或者如果你可以把新詞存入字典，那麼你可以簡單地用它的MD5來索引它，以32位，或4字節，或4個三字母詞；給你xykjimsuptitbat。xyk前綴現在告訴解碼器後面是 32 位 MD5 散列。發送者和接收者必須就字典達成一致，現在他們還需要保持同步。
你的加密句子會變成類似
Fence, xykjimsuptitbat! Normal bog nuclear cascade iron irksome Welcome japanese brillig sympathetic Anathematize copper bleat irksome kill airplane Severn'emporium zip cascade enormous這是第二個（也可能是第三個）問題：在長文本中，有些單詞會重複出現，便於分析。在這裡，irksome和cascade各出現兩次。這讓人懷疑它們（或至少其中一個）可能是一個常見的英語單詞，例如“it”、“the”、“of”或類似的東西。就像數據庫應用程序需要警惕小 Bobby Tables一樣，這種加密方案需要害怕年輕的Etaoin。
此外，您知道哪些詞不常見（通過它們的前綴），因此您可以一眼就分辨出普通句子和*“Twas brillig”和“slithy toves…”*。
請注意標點符號被保留，因此很容易推測emporium是*’ll*、’m、’s、’t或*’ve*；沒有太多的英文單詞包含引號（一打？二十？還是太少）。
加密除了非常短的文本之外的任何內容，並且很少這樣做，這意味著攻擊者將（相對）快速發現xykjimsuptitbat實際上意味著supercalifragilisticexpialidocious。換句話說，這不是加密——它“僅僅是”混淆。
那麼……為什麼會有這麼“危險”的要求呢？
我會冒昧地猜測您需要它才能對加密文本進行搜尋。有一些技術可以讓您安全地執行此操作，但它們都利用了正在執行的搜尋的某些功能；換句話說，沒有一種萬能的解決方案也被證明是安全的（即證明至少與一些經過證明的解決方案一樣安全，或者至少是被廣泛採用的解決方案）。但是，如果您提供更多資訊，我們可能會提供幫助。
或者，當然，您可能完全出於其他原因需要它——但在不知道原因的情況下*，很難提出一個how*。
一些搜尋方案
有幾種可能的“搜尋”。首先讓我們考慮一下所有搜尋都必然會洩露一些資訊，如果你允許足夠強大的搜尋，這完全等同於讓文本不加密（你基本上用密文執行（某種）劊子手游戲——所謂的甲骨文攻擊）。
現在，“搜尋”可以是查詢“給定集合中哪些記錄包含特定關鍵字？”或“哪些記錄包含此任意關鍵字？”或“哪些記錄包含此任意使用者提供的文本？”的操作，或甚至“什麼記錄匹配這個正則表達式？”。在這個問題上已經做了很多工作；嘗試使用Google搜尋“PEKS”。
最簡單（也是最安全）的情況是您擁有一組固定的關鍵字。所以在記錄中
1: Shall I compare thee to a summer's day? 2: Thou art more lovely and more temperate.你可以按你、天、藝術或你來搜尋，但不能按夏天。
您可以通過簡單地將帶有關鍵字的序列附加到加密文本來實現這一點 - 這也可以是明文：
1: blindalasbirigudacomefosseantani|Thee|Day 2: tarapiatapiocalasupercazzolaprematurata|Thou|Art在搜尋Thou之後，我們知道它包含在記錄 2 中，僅此而已。如您所見，我們儲存的關鍵字越多，我們的安全性就越低。儲存所有關鍵字，你還不如根本不加密。
通過注意到加密文本實際上從未使用過，上述方案可以更加節省空間，因此您可以只儲存關鍵字。
否則，我們只是在混淆；因此，我們不妨去追求性能。
例如，您可以用所謂的“蠕蟲”（我們在此討論 Vigenère 密碼）對所有記錄進行 XOR，例如 16 個字節，並將所有字母擴展為它們的十六進制等價物。生成的文本容易受到幾種可能的攻擊，但仍可被認為是“加密的”。要進行搜尋，您可以將搜尋字元串與蠕蟲的 16 次可能旋轉進行異或運算 - SAYHELLOWORLDNOW、AYHELLOWORLDNOWS、YHELLOWORLDNOWSA…，對其進行十六進制編碼，並將結果用作普通文本搜尋。根據儲存檢索性能，它會慢 1.x 到 16 倍，但它會起作用。
最有希望的可能性存在於實際搜尋不受搜尋者控制的地方——他可以向搜尋引擎送出文本，但不能代表搜尋引擎採取行動，例如，送出和檢索速度受到限制（在其他情況下）的話，大規模字典/預言機攻擊沒有真正的可行性）。例如，您可以擁有一個帶有搜尋功能的 MySQL 引擎，該引擎實現為閉源、可載入的 UDF 模組。