為什麼通用散列函式可以防止對手，而統一散列函式卻不能？
在我陳述我的實際問題之前，讓我先來五個術語，以便我們都在同一頁上：
讓 $ U={k_1,…,k_u} $ 可能的鑰匙的宇宙， $ |U|=u $ . 我們使用雜湊表 $ T $ 和 $ m $ 細胞，從 $ 0 $ 至 $ m-1 $ . 我們使用一系列雜湊函式 $ H $ , 這樣每個 $ h\in H $ 有可能 $ 1/m $ 那兩個不同的鍵 $ k $ 和 $ k’ $ 雜湊所以相同的值，即 $ P(h(k)=h(k’))=1/m $ .
最後，通用散列意味著對於散列，一個隨機散列函式（滿足 $ 1/m $ 上面提到的要求）是從H中選擇的。根據我的研究（這似乎與著名的CLRS算法教科書一致），我們總是只使用一個我們雜湊表的整個執行時的雜湊函式。因此，散列系列中的其他元素僅在創建表時（即，在第一次程序呼叫時）才相關，但是這個函式被選擇為固定的，而所有其他元素不再相關。這也是有道理的，因為如果你要為不同的鍵選擇不同的雜湊函式，那麼你需要再次從鍵到使用的函式的映射——這沒有多大意義，這就是我們要解決的問題：知道在哪裡儲存密鑰；但是選擇的散列函式將依賴於密鑰，所以我們會遇到一個悖論。:) 所以我們在整個執行時只選擇一個函式是非常合乎邏輯的。
澄清後，我的問題：
如果隨機散列函式在表的生命週期內仍然是固定的，那麼選擇一個隨機散列函式如何幫助我們防禦對手？我看不出與預先固定單個散列函式有任何區別。
任何單一講座和學術材料中提到的唯一動機是讓對手的生活更加艱難，因為對於任何固定的雜湊函式，我們可以設計一系列雜湊到相同值的鍵，從而導致雜湊表的最壞情況行為。所以聲稱，由於我們現在選擇了一個隨機散列函式，你不再知道正在使用哪個，所以你也不能設計這樣的攻擊密鑰序列。我只是不贊成這種說法。
在創建具有通用散列的散列表後，您還可以找到一個散列函式，您可以為其找到這樣的序列，因此我們確實沒有解決問題。我相信重要的問題是對手應該從哪裡知道正在使用哪個雜湊函式！
所以，如果我們只使用一個雜湊函式，甚至將其公開，那麼你當然會受到攻擊。但是為什麼該功能應該是公開的呢？程式碼幾乎從不公開，是嗎？因此，假設程式碼不是公開的，那麼攻擊者無論如何都不知道使用了哪個雜湊函式——無論您是從全家中隨機挑選一個還是隨機挑選一個。
因此，如果我們假設該函式不是公開的，並且攻擊者可以“以某種方式”推斷出它（這甚至可能嗎？例如通過測量執行時間？），那麼是否有一個預先修復的函式也沒有什麼區別或者是否僅在表初始化後才修復。
因此，無論哪種方式，對手的論點似乎都不起作用——除非使用的雜湊函式實際上是公開的，否則它似乎是錯誤的，我簡直不敢相信。那麼這裡發生了什麼？
實際上，在雜湊表的應用中，在通用雜湊函式族中隨機選擇雜湊函式的基本原理是確保使用雜湊表的對手不知道我們選擇了哪個雜湊函式。再加上通用散列函式家族的特性，使得攻擊者無法故意製造散列衝突。
程式碼幾乎從不公開，是嗎？
根據Kerckhoffs 的（第二個）原則，我們必須假設對手知道程式碼。這反映了這樣一個事實，即攻擊者經常可以訪問目標程式碼，並且（儘管需要付出努力）可以對其所做的事情進行逆向工程（此外，開源軟體越來越普遍）。因此，我們沒有假設程式碼是秘密的，而是假設通用散列函式族中散列函式的選擇是隨機和秘密的。至少在最初這是一個合理的假設，因為選擇是在執行時，應用程序啟動時（或者，對於數據庫，在創建數據庫時）做出的，因此單獨的程式碼分析無助於確定這個選擇。
重要的是，實現應該嘗試使該選擇不會洩漏，例如通過定時側通道。這非常困難，因為我們避免碰撞是因為它們會減慢速度，因此碰撞本質上可以通過時間檢測到。