用戶是最大的漏洞

        從安全方面來說，用戶是系統中最薄弱的環節。不過「聰明的」用戶總是會找出各種理由把責任推卸給「技術」。甚至研究者有時也會落入這種陷阱。

        不久前在知乎上有一個關于 MD5 的討論。 不得不說 MD5 是一種非常弱的 hash 算法。考慮到使用 SHA-1 等更強算法的額外負擔完全可以忽略，我建議無條件的避免使用 MD5。但是從另一個方面來說，到底多少安全問題真正的責任在于 hash 算法的脆弱性？我在知乎上的總結是這樣的（下面有些描述是符號化的，但在知乎上用的是非符號化語言。如果二者造成理解上的差異我為知乎上的不準確抱歉）：

        給定一個 hash 算法 f (x)，對 f (x) 的「破解」有下面幾種方法（注意「破解」不能等同于攻擊。破解是非蠻力攻擊。所以以下方式均有「比窮舉算法效率更高」這個限制）：

        1、使用比窮舉算法效率更高的方法得到 x1 和 x2，滿足 f (x1) = f (x2)；（可稱為隨機盲目碰撞）

        2、給定 x1，使用比窮舉算法效率更高的方法得到 x2，滿足 f (x1) = f (x2)；

        3、給定 x1，使用比窮舉算法效率更高的方法得到滿足約束 A 的 x2，滿足 f (x1) = f (x2)。約束 A 越嚴格，達成實質攻擊的可能越大。比如，若 A 是描述自然的英語或者漢語，則任意的簽名欺詐可行矣。

        目前在理論界只有破解方式 1 得到了一些針對 MD5 級別的弱 hash 算法的突破。方式 2 和 3 在理論上的可能性也還未證實，甚至于對最弱的 hash 算法即使用蠻力也無法得到方式 3 中真正可以施行欺詐的 x2。我認為方式 1 很難達成實質的攻擊。但是有研究者不同意這個觀點（本地存檔）。這個鏈接給出了一個方法，通過方式 1 的隨機盲目碰撞也能達成實質的數字簽名欺詐。果真如此嗎？

        錯！

        （以下描述需要理解剛才給出的鏈接內容）

        Caesar 的錯誤不在于使用了弱 hash 算法，而是他輕易相信了 Alice 給他的 PostScript 格式的文件。他沒有審查這個文件的實質代碼（盡管 PostScript 文件的源代碼實際上是可讀的），而是輕信了一個 PostScript viewer 一時 render 出來的外觀就匆匆地數字簽名了。如果把 PostScript 文件變成可執行文件，把 PostScript viewer 變成操作系統，Caesar 變成某家水果公司。那么以上關于 Caesar 和 Alice 的情景無異于：一個開發者給水果公司一個 app，水果公司運行了一下發現沒問題，然后水果公司就用公司證書給這個 app 簽名并將簽名后的 app 發回給開發者了。那么水果公司因此背上任何黑鍋都是咎由自取。事實是：

        ▲水果公司不會用自己的證書，而是用自己的證書認證開發者證書，然后要求開發者用自己的開發者證書簽名；

        ▲水果公司要保留追溯開發者的機制，在后期發現 app 違規時可以追加懲罰。

        所以，數字簽名技術提供的信任是有約束的。對簡單的可審查文件（如純文本）才能任意簽署。對復雜的不可審查文件（如可執行文件，復雜結構化文 檔，特別是帶有動態內容的文檔 —— 其實質等同于可執行文件，有些甚至達到了 Tuning-complete 級別）必須堅持「誰產生誰簽署」的原則，而且必須有后續的法律追溯機制。更近一步說，對復雜的不可審查文件的輕信是任何技術都無法挽救的安全潰敗。

        其實上文提到的這個研究者在最后一頁中提到了采用其它文件格式作為解決方法。但是他明顯認為和采用更強的 hash 算法相比這是一個次要因素，而且他提出的居然是 Word 文檔，一種內在格式和外觀差異與 PostScript 不相上下的格式，而非「所見即所存」的簡單文本格式。我曾經參與過幾次安全培訓，那些很有經驗的講師一般也會在幾天的培訓里不經意舉出一兩個他們認為的技 術上的安全漏洞，而實為用戶「盲目輕信」導致的問題。從信噪比的角度看，這些疏忽對那些安全專家的知識價值可說瑕不掩瑜，但也說明在人類心理和行為模式方 面的安全才是最脆弱的。