長度擴展攻擊疑點

Question

所以我一直在研究這個長度擴展攻擊的概念，在我的研究過程中我注意到的一些事情對我來說並不是很清楚。

1.研究論文正在解釋如何將 append 某種類型的數據到底並制作新的數據。 例如

所需的新數據：count=10&lat=37.351&user_id=1&long=-119.827& waffle =eggo& waffle =liege

（注意 2 華夫餅）。 我的問題是，如果服務器端的解析器 function 可以跟蹤重復屬性，那么整個長度擴展攻擊會是無稽之談嗎？ 因為服務器會注意到重復的屬性。 用於檢查任何重復項的適當解析器是否是與長度擴展攻擊相比的良好解決方案？ 我知道 HMAC 方法和其他保護措施，但現在在這里專門討論解析器。

2.Research 說只有易受攻擊的數據是 H(key|message)。 他們聲稱 H(message|key) 對攻擊者不起作用，因為我們必須 append 一個新密鑰（我們顯然不知道）。 我的問題是為什么我們必須給 append 一個新密鑰？ 我們在攻擊 H(key|message) 時不會這樣做。 為什么我們不能相信我們將通過驗證測試（我們將創建正確的哈希），並且如果解析器試圖從中提取密鑰，它將獲取我們發送的塊中的唯一密鑰並從那里恢復？ 為什么我們必須發送 2 個密鑰？ 為什么對 H(message|key) 的攻擊不起作用？

Answer 1

1. 我的問題是，如果服務器端的解析器 function 可以跟蹤重復屬性，那么整個長度擴展攻擊會是無稽之談嗎？ 您正在談論一個編寫良好的解析器。 編寫軟件很難，編寫正確的軟件非常困難。

在該示例中，您已經看到了一個被覆蓋的屬性。 你能說一個好的解析器必須取最后一個還是第一個？ 規則是什么？ 可能有最后一個必須乘坐的車站。 這是一種可以應用或不應用的攻擊。 這取決於車站。 如果你認為長度擴展攻擊的知識可以追溯到 1990 年代，那么找到一個適用於此的地方應該會讓人感到驚訝。而且，它在 2009 年被廣泛應用於 Flickr API； 近20年后；

• Flickr 的 API 簽名偽造由 Thai Duong 和 Juliano Rizzo 於 2009 年 9 月 28 日發布。

2. 我的問題是為什么我們要 append 新密鑰？ 我們在攻擊 H(key|message) 時不會這樣做。 為什么我們不能傳遞我們將通過驗證測試（我們將創建正確的哈希）以及如果解析器試圖從中提取密鑰，它將獲取我們發送的塊中唯一的密鑰並從那里恢復的事實. 為什么我們必須發送 2 個密鑰？ 為什么對 H(message|key) 的攻擊不起作用？

攻擊是簽名偽造。 攻擊者不知道密鑰，但他們仍然可以偽造新的簽名。 新消息和簽名 - 擴展 hash - 被發送到服務器，然后服務器獲取密鑰並將其附加到消息中以執行規范驗證，即； 如果確實如此，則簽名有效。

解析器不提取密鑰，它已經知道密鑰。 關鍵是你能確定數據是否真的被擴展了。 填充規則很簡單，加1並填充許多零，這樣最后64位（128）就是長度編碼（非常簡單，例如SHA256的最終長度必須是512的倍數）。 要查看內部是否有另一個填充，您必須檢查每個塊，然后您可以聲稱存在擴展攻擊。 是的，您可以這樣做，但是，密碼學的目標之一也是減少依賴關系。 如果我們可以創建一個更好的簽名來消除檢查，那么我們建議留下其他人。 這使軟件開發人員能夠輕松編寫更安全的實現。

為什么對 H(message|key) 的攻擊不起作用？

很簡單，您獲取擴展消息message|extended並將擴展 hash H(message|key|extended)發送到服務器。 然后服務器獲取消息message|extended並附加密鑰message|extended|key並將其散列H(message|extended|key)顯然這不等於擴展的H(message|key|extended)

請注意，SHA2 系列的修剪版本（如 SHA-512/256）具有抗長度擴展攻擊的能力。 SHA3 在設計上不受它的影響，並且可以實現簡單的 KMAC 簽名方案。 Blake2也是免疫的，因為它采用HAIFA結構設計。