Authentication

固定長度的消息真的需要 HMAC 結構嗎?

  • June 21, 2015

HMAC 構造定義為:

Hash( (Key XOR opad) || Hash((Key XOR ipad) || Message) )

這是因為更簡單的結構而設計的,例如:

Hash(Key || Message)

容易受到長度擴展攻擊(但並非針對所有雜湊,一個顯著的例外是 SHA-3)。

問題是,消息的情況如何:

  1. 具有已知的固定長度,如果長度與預期長度不同(例如,CBC-MAC 對於固定長度的消息是安全的,但對於可變長度的消息則不安全),則會被拒絕。
  2. 在消息的開頭加上固定大小的長度指示符(即擴展消息是Fixed-Sized Length indicator||Message,散列是:)Hash(Key||Fixed-Sized Length indicator||Message)
  3. 與前一個方案相同的方案,但長度指示符僅包含在散列中。

(這些可能是完全不同的情況,因此請單獨考慮)。

請注意,對於 (3),另一種配置Hash(Fixed-Sized Length indicator||Key||Message)將保證長度指示符包含在散列的第一個塊中 - 我的意思是,即使對於大於散列函式塊長度的巨大密鑰也是如此。長度指示符可能不需要超過 64 位的大小(因為大多數

$$ older $$2^64 - 1無論如何,雜湊都限制為最大消息大小)。這讓人很難想像它怎麼會不安全?但我猜我不是密碼學家。

我將以反手的方式同意@fgrieu上面的精彩文章。

我的回答是:,您不必使用**HMAC。無論如何都要這樣做。

正如您所指出的,一些雜湊、sush 為SHA-3(尤其是其Keccak形式)、Skein(我曾是其團隊成員)以及其他的都可以正常工作。在Skein的情況下,有一個一次性Skein-MAC具有由 Mihir Bellare(也是Skein團隊成員)有趣地完成的安全證明,他做了上面提到的@fgrieu的HMAC證明。

此外,我和其他一些人(包括另一位Skein團隊成員 Niels Ferguson)對**HMAC提出了批評,即HMAC本質上假設了一個有效的雜湊函式。HMAC可以防止許多散列函式的破壞,包括 Merkle-Dåmgard 長度擴展攻擊,但我們不知道它對於具有任何類型弱點的散列函式有多好。我不認為我們有任何想法,例如,HMAC-MD5HMAC-MD4有多好,儘管它們中的每一個都有可怕的中斷。(MD5很容易用電腦破解;MD4很容易用鉛筆和紙破解。)您可以在上面的 @fgrieu的關於假設 F 是理想 PRF 的評論。如果已知 F 是具有一整套缺陷的非理想 PRF 怎麼辦?那麼HMAC有多好呢?

您已經描述了一堆很可能與現實世界中可能看到的散列函式一起工作的結構,例如SHA-1SHA-256SHA-512SHA-512/ z仍然已知有弱點。更好的是 Key-Length || 的雜湊值 鍵 || 消息長度 || 資訊。

但是無論如何都要進行HMAC,除非您需要從SkeinKeccak/SHA-3獲得的一次性 MAC 。作為需要的範例,ZRTP 協議允許使用SHA-1 HMACSkein-MAC(再次完全公開,我是該協議的合著者和此用途的實施者)。原因是如果你在做HMAC,那麼協議的大部分計算時間都花在了HMAC上。儘管如此,它只是一個回退到始終存在的HMAC的選項。

你想做HMAC的原因是我在做加密時學到的一個元原則:不要做任何愚蠢的人認為愚蠢的事情。將此視為格言的推論,“永遠不要與白痴爭論,人們可能無法分辨其中的區別。” 這是諷刺和貶義的,所以我們也稱它為貓王科斯特洛偵探原則,“不要變得可愛。” 因此,讓我們從現實世界的角度來看它。

我認為您的構造在任何實際情況下都很好。但如果我們錯了怎麼辦?除非有像 Mihir Bellare 這樣在協議證明方面受人尊敬的人為此做證明,否則我們總是支持你沒有證明的八球,這是一個公平的警察!即使您指出這些安全證明有自己的一套假設並且值得懷疑(尤其是在 Paterson 等人的 SSH 中斷之後——這是另一個完整的討論),事實是有 HMAC 的證明而不是為您的(除非您使用已知良好的 MAC 雜湊,如 Skein 或 Keccak)。

我可以想出一些方法來通過使用愚蠢的編碼來打破這種結構。(這是一個手波:使計數器成為一個固定長度的二進制計數器,而不是實際長度的 ASCII 字元串。包裝計數器,使衝突消息具有相同的長度 mod 2^n(例如 1 對 257一個字節計數器或 65537 用於兩字節計數器)然後繼續進行長度擴展攻擊。)這是大規模的面部手掌破壞,但這不是第一次有人做出大規模的面部手掌破壞編碼錯誤。事實上,這樣的事情每天都在發生。

我開始相信好的加密貨幣的一個重要屬性是可以理解的。HMAC相對於改進的鍵控散列等結構的優勢在於,閱讀您的協議的人可以說“哦,這是一個HMAC ”並繼續前進,而不必閱讀所有細節並記住這些改進在哪些情況下有效。此外,如果你使用不標準的東西,人們會抱怨。這些抱怨不會消失。即使你寫了無數篇關於你做得很好的部落格文章,人們仍然會抱怨。而如果您使用HMAC,他們不會。沒有投訴的代價僅僅是對雜湊函式的第二次呼叫。如果僅僅第二次呼叫實際上是一個很大的成本(就像 ZRTP 一樣),那麼您可以使用帶有安全證明的一次性系統!

你所暗示的最終問題是你變得可愛了。HMAC的存在是為了解決密鑰散列的已知問題。它有一個安全證明,表明它達到了這個目標。它有在該領域有用的歷史。即使是對那個證明和使用歷史的合理批評也不能支持你變得可愛的方式,即使我認為你的可愛已經足夠安全,我知道除了舔我的手指並堅持它之外我沒有別的辦法在風中支持我。

總而言之,,您不必使用**HMAC。無論如何都要這樣做。

總結:的,HMAC 是從任意具體的迭代雜湊構造 MAC 的方法。我們對問題中 MAC 結構的安全性沒有建設性的論據;我們甚至在使用一些看起來很精細的雜湊時都會進行具體的攻擊。


我考慮通過迭代壓縮函式構造的雜湊 $ F $ 作為 $ s_{i+1}=F(s_i,m_i) $ 和 $ s_i $ 的 $ h $ 位(也是 MAC 的大小)、消息塊 $ m_i $ 大小的 $ b $ ,也許是Merkle-Dåmgard強化(這匹配 MD5、SHA-1、SHA-2,但不匹配 Keccak/SHA-3);我也假設Key是固定大小的,輸入 $ m_0 $ ,第三個構造是Hash(Fixed-Sized Length indicator||Key||Message)

在假設下 $ F $ 是一個理想的 PRF,問題中的三個結構似乎是安全的,但可能在某些次優程度上。我看到的最好的一般攻擊(即,無論迭代函式的細節如何都有效)是獲取相同大小的消息的雜湊(至少 $ \max(2b,h)+b $ ),消息的開頭是隨機的,最後一個消息塊是固定的,直到在不同的消息塊之間發現衝突 $ m_0 $ 和 $ m_1 $ (這需要 $ \mathcal O(2^{h/2}) $ MAC);然後獲取MAC $ \widetilde{m_0} $ 最後一位切換;MAC 將很有可能對類似的修改也有效 $ \widetilde{m_1} $ . 這是對 MAC 的有效攻擊。它之所以起作用,是因為 MAC 之間的衝突 $ m_0 $ 和 $ m_1 $ 很有可能在最後一個區塊之前發生,在這種情況下 $ \widetilde{m_0} $ 和 $ \widetilde{m_1} $ 也必然會發生碰撞。

上述通用攻擊確實適用於 HMAC(和 CBC-MAC,以及任何一次通過的迭代 MAC)。然而,HMAC(與其他構造相反)帶有安全論點,即沒有漸近更好的攻擊,甚至在迭代函式的假設相對較弱的情況下也有效的論點;參見 Mihir Bellare: New Proofs for NMAC and HMAC: Security without Collision-Resistance ,並在 Crypto 2006 中進行了擴展摘要。

HMAC 的安全參數,以及密鑰在計算開始和結束時都輸入的事實(這反過來又確保了,在上述攻擊中,攻擊者不知道沖突值),給了我們一個安全邊際。我有理由相信 HMAC-MD5 在幾年內不會被實際破壞(不包括對諸如 DPA 或註入故障等實現的攻擊),但我對由 MD5 建構的 MAC 並不像問題中那樣有信心。補充:這句話有很多道理:安全總比後悔好。

為了說明 HMAC 的優越性,我們可以製作一個迭代雜湊,使得這三個結構很弱,但 HMAC 仍然很強大。一個例子是 SHA-256 通過刪除 8 個加法模 $ 2^{32} $ 在一輪的第4步(最後一步)中(使 $ H_0^{(i)}=a $ , .., $ H_7^{(i)}=h $ )。如果對修改後的 SHA-256 的抗碰撞性或(第一或第二)原像抗性進行攻擊,我看不到它(更新:再想一想,我看到的最好的是與此類似的原像攻擊,與費用大約 $ 2^{128} $ 而不是 $ 2^{256} $ 對於完整的 SHA-256)。但是,在問題的構造中,從單個消息/MAC 對中,很容易計算相同長度的任何消息在第一個之後的塊中不同的 MAC(請注意,對於已知塊和輸出,可以走回雜湊狀態)。[在強烈批評評論之後添加:我推理的一個關鍵點是,在使用修改後的 SHA-256 時,HMAC 的安全論點似乎適用;如果無法彌補,我將承認一個差距;或者,如果由於雜湊的安全性有一個被廣泛接受的定義,那麼這個修改後的 SHA-256 失敗(至少在數量上),但 SHA-256 通過(注意 SHA-256,與 Keccak/SHA-3 相反,微不足道失敗由於長度擴展屬性而被廣泛接受的安全定義)]。

引用自:https://crypto.stackexchange.com/questions/25693