使用散列函式傳輸和隱藏密文？
可以使用散列函式來傳輸和隱藏密文嗎？
這個有點相似的鎖定問題，“如果加密雜湊是完全唯一的，理論上它們可以用來傳輸數據嗎？”，收到了幾個令人信服的沒有答案，但考慮一下：
Alice 和 Bob 共享一個秘密：
/p68J5gd3%}"jd9fkg;BtiAraGgsioe2:L<76e7emOngehf]jfur80}{_kod*6Alice 將她的密文添加
JWHSM到她的秘密副本中：/p68J5gd3%}"jd9fkg;BtiAraGgsioe2:L<76e7emOngehf]jfur80}{_kod*6 || JWHSM現在她使用 SHA-512 散列（秘密 + 消息）並將散列發送給 Bob。
Bob 知道他必須進行一些計算並找到將連接並解析為 Alice 發送的雜湊值的密文，並且他知道會有多少個字元（在這種情況下為 5 個）。因此，實際上，Alice 向 Bob 發送了一條他無法立即閱讀的消息，但他可以解決它。他們想要擊敗流量分析的某些方面，並且他們懷疑 Mr. Attacker 可能能夠對他們發送的每個散列進行簡單的原像攻擊——他們回應“那又怎樣？”
可以使用散列函式以這種非正統、昂貴的方式傳輸和隱藏密文嗎？
是的，您可以使用雜湊來“隱藏”這樣的消息。但是，與正常的對稱加密相比，我沒有看到任何優勢，後者已經能夠返回一個隨機化的密文。
正如我所理解的那樣，隨機化本身並不是隱寫術。完全隨機化的消息可能會脫穎而出，無論是單獨出現還是簡單地複製到消息中。讓我們做一個小小的思考實驗：有點麻煩，您可以創建一個塊大小與散列函式的輸出大小相同的塊密碼。我看不出您的方案與該特定密碼有何不同，或者在隱藏明文/密文方面做得更好。
讓我們看看缺點：
- 首先，接收方需要執行的工作量相對較大。
- 其次，該方法的規模非常糟糕。你可能只有 $ 2^{32} $ 明文/密文對，這已經在消耗 CPU 資源。
- 第三，密文比它需要的大得多，即使它是靜態的並且受限於輸出大小。
- 最後，由於沒有 IV，如果您發送多條消息，因為密文會重複，這在語義上是不安全的。
至於第四點：引入密文的完全隨機IV發送當然是可能的，但它會進一步擴展密文。
如果在已經使用雜湊的情況下使用此程式碼，我可以看到一些優勢，例如在簽名生成或 HMAC 中驗證未加密消息（或具有已知大小的加密消息）時。在這種情況下，其他數據已經存在，無需猜測。然後可以使用該方案創建一個潛意識通道，我猜這與隱寫術有關。
當然，您需要確保附加消息卡在末尾，而不是在前面，這樣您只需對發送消息進行散列處理一次（可能除了最後一個塊）。至於簽名生成：您可能希望使用 PKCS#1 v1.5 填充來檢索完整的雜湊。請注意，對於簽名，攻擊者將能夠看到原始雜湊/簽名無法驗證，這否定了消息的隱藏。