使用公鑰的假名化散列
我有包含敏感數據（郵件地址、使用者名等）的日誌，這些數據不僅需要符合 GDPR，而且通常盡可能地得到保護，因此匿名/散列將是一個簡單的解決方案。但是，與此同時，我需要能夠關聯資訊以用於監控目的（例如辨識攻擊）。為此，明文值是不相關的，但我需要假名散列對於相同的明文源（確定性）是相等的。由於我不能以純文字形式儲存數據，而只能以假名方式儲存，因此我還需要能夠在必要時解密這些值。由於可能有多個數據源需要單獨解密（很少需要一次全部解密），我最初的想法是使用使用 RSA 的普通舊公鑰/私鑰方法，這是我從 SSH 日常工作中知道的-天：使用每個源的公鑰加密值，將私鑰儲存在保險箱中。然而，RSA 為雜湊引入了隨機性，從安全的角度來看這是有道理的，但破壞了我的“必須能夠關聯”確定性要求。
關於一個好的解決方案的任何想法？有沒有我可以使用的類似算法不太容易暴力破解，但可以使用公鑰/私鑰方法？我是否錯過了其他弱點，例如嘗試在沒有隨機填充的情況下使用原始 RSA？
在操作方面：攻擊者可能訪問大量雜湊的風險比他訪問已經高度安全的公鑰的風險要高得多。已確定的最大風險（仍然非常不可能）是攻擊者可能能夠在要處理/加密的管道源處注入他自己的數據，然後查看雜湊值，從而允許他比較明文和雜湊值（= 猜測雜湊值）。加密速度不需要很高，解密速度就更不重要了。
如果相關，實際實現將需要使用 Python 完成。
您似乎要求的是某種類型的公鑰收斂加密，確實存在各種方案。
然而，如果合理明文的數量很少——比如說，少於大約 septillion ( $ 10^{24} ≈ 2^{80} $ ).
具體來說，擁有消息的收斂密文（或只是加密雜湊）和用於生成它的公鑰（如果有）的攻擊者可以猜測一個合理的明文，對其進行加密並將其與密文/雜湊進行比較，以驗證是否他們的猜測是否正確。
一個典型的台式機 CPU 可以處理大約十億 ( $ 10^9 ≈ 2^{30} $ ) 加密一秒鐘，所以如果可能的明文比這少，則該方案根本不提供真正的安全性。如果攻擊者願意花更多的時間和/或購買（或竊取）更多的計算能力，他們可能會暴力破解一千、一百萬或十億倍的明文。此外，以這種方式同時攻擊多個密文與攻擊單個密文一樣快。
可以使用密鑰擴展方案來減慢此類攻擊，但代價是將合法加密（和解密）操作減慢大致相同的因素。因此，例如，如果您可以忍受單個加密操作大約需要 1 個 CPU 秒，那麼您可以強制攻擊者也需要大約 1 個 CPU 秒（根據實施效率給予或採用 10 或 100 倍）來猜測並測試一個合理的明文。但這仍然意味著可以訪問 100 個 CPU（或者可能是一個快速 GPU）的攻擊者仍然可以在大約三個小時內測試一百萬個可能的明文。
通常，諸如郵件地址、使用者名、電話號碼等數據的基數相當低——更糟糕的是，即使可能有數百萬或數十億個可能的地址，使用中的可能地址組合也要少得多，而且使用 public 很容易發現地圖和地址數據庫。因此，在實踐中，使用密碼散列或收斂加密對此類數據進行假名化注定會失敗。
相反，您可以執行以下操作之一（大致按偏好降序排列）：
- 如果可以避免，請勿儲存或處理此類數據。
- 如果您必須儲存此類數據，請將其加密儲存（使用傳統的選擇明文抗攻擊加密方案）並僅將其解密以在安全系統上進行處理。安全地儲存解密密鑰。
- 如果您必須對此類數據進行假名化，例如由不受信任的第三方處理，最好將每個數據（地址、使用者名等）與完全隨機的標識符相關聯，並將關聯儲存在加密數據庫中。確保如上所述保持此關聯數據庫的安全。
或者，您可以通過將PRF（例如HMAC或一些密鑰拉伸KDF）應用到具有密鑰的敏感數據項來生成假名標識符。如果是這樣，您必須保護 PRF 密鑰免遭洩露，因為它可用於對所有數據進行去假名化。
無論哪種方式，“在源頭”進行假名化通常是不可行的。相反，您應該在收集點使用安全的公鑰方案加密任何敏感數據（它應該只能訪問密鑰對的公共部分），將此加密數據收集到安全系統中並解密、處理和（可選) 在那裡化名。