題:
如何以及何時使用HMAC?
user5575
2012-09-13 16:22:23 UTC
view on stackexchange narkive permalink

我正在閱讀Wikipedia上的 HMAC,我對此有些困惑。

  1. 我在哪裡使用HMAC?
  2. 為什麼是哈希的關鍵部分?
  3. 即使有人成功使用了“長度擴展攻擊”,這對攻擊者有什麼用?
  4. ol>
如果有人好奇,我想知道的是hmac是使用“對稱”密鑰簽名數據的一種方式。 “這比將消息和密鑰散列在一起更複雜,這是不安全的”,這是一個好處。
我的一個朋友經營著世界上最大的“加密貨幣”交易所之一。他的API需要使用用戶專用api密鑰(這是您在問題中所指的“秘密”)對用戶的所有api調用進行HMAC簽名,其中包括哈希中的公用密鑰。這是基本用例,是API調用的附加安全層。在加密貨幣世界中,儘管進行了數百萬次嘗試,他仍然是唯一一個被黑客入侵的平台。 HMAC非常有用,只需確保您知道如何使用它即可。我以為我做到了,但是沒有,並且以毀滅性的API駭客的形式付出了代價。
用這個來調試https://8gwifi.org/hmacgen.jsp
五 答案:
Gilles 'SO- stop being evil'
2012-09-18 06:01:50 UTC
view on stackexchange narkive permalink

通過MAC算法從消息和密鑰生成消息驗證碼(MAC)。 MAC的一個重要特性是不可能在不知道密鑰的情況下產生消息和密鑰的MAC。由不同密鑰產生的同一消息的MAC看起來無關緊要。即使知道其他消息的MAC也無助於計算新消息的MAC。

HMAC是基於哈希函數 s>的MAC一個>。基本思想是將密鑰和消息連接在一起,並將它們哈希在一起。由於不可能給定密碼散列來找出它的散列,因此知道該散列(甚至是此類散列的集合)就不可能找到密鑰。基本思想還沒有完全解決,部分原因是長度擴展攻擊,因此實際的HMAC構造要復雜一些。有關更多信息,請瀏覽在密碼棧交換上的hmac標記,尤其是為什麼H(k || x)不是安全的MAC結構? H( k || length || x)安全的MAC結構? HMAC與MAC功能。還有其他定義MAC的方法,例如基於分組密碼的MAC算法,例如 CMAC

MAC 對消息進行身份驗證。如果Alice看到一條消息和一個MAC並且知道相關的密鑰,則她可以通過自己進行MAC計算來驗證該MAC是由知道該密鑰的委託人產生的。因此,如果消息附帶正確的MAC,則表示該消息在某個時候被秘密密鑰的持有者看到。 MAC是基於密鑰的簽名,它提供與基於公鑰加密的簽名方案類似的保證,例如基於RSA的方案,其中籤名必須由擁有以下內容的委託人產生私鑰。

例如,假設愛麗絲將自己的秘密密鑰保留給自己,並且僅使用它來計算她存儲在雲服務器或其他不可靠的存儲介質上的消息的MAC。如果她以後回讀一條消息並看到正確的MAC,則可以知道這是她過去存儲的消息之一。

HMAC本身並不提供消息完整性。它可以是提供完整性的協議中的組件之一。例如,假設愛麗絲將多個文件的後續版本及其MAC存儲在不可靠的介質上。 (同樣,我們假設只有愛麗絲知道密鑰。)如果她回讀了具有正確MAC的文件,則她知道回讀的內容是所存儲文件的某個先前版本。控制存儲介質的攻擊者仍可能返回文件的舊版本或其他文件。在這種情況下,提供存儲完整性的一種可能方法是將文件名和版本號作為其MAC計算數據的一部分。愛麗絲需要記住每個文件的最新版本號,以確保沒有給她提供過時的數據。確保完整性的另一種方法是讓Alice記住每個文件的MAC(但在這種特定情況下,哈希也可以做到)。

¹“不可能”比實際可能更多的計算能力。 sub>

我發現這有點不清楚和冗長,儘管我確實學到了一些
可以共享hmac代碼嗎?這似乎讓我感到困惑-這是一個哈希,但無法共享。
@R11G我不明白您的問題。請注意,“這是哈希”不是理解HMAC的有用方法。HMAC是MAC。它基於哈希的事實是實現細節。還有其他MAC算法具有相同的安全性屬性,但內部不使用哈希,例如CMAC。
-1
@R11G這取決於它的HMAC和目標安全性。沒有密鑰,您無法從HMAC返回到輸入。即使使用該鍵,也只能通過猜測輸入並進行檢查來返回。但是,如果兩次看到相同的HMAC,則知道它必須是具有相同鍵的相同輸入。
為什麼“ HMAC”不提供消息完整性?維基百科和其他答案說它確實提供消息整數,我認為是這樣。“與任何MAC一樣,它可用於同時驗證數據完整性和消息的身份驗證。”---來自維基百科
@Rick不幸的是,這常常是一種微妙的說法。假設您從不受信任的來源收到消息和該消息的推定HMAC。您使用適用的密鑰計算了消息的HMAC,然後看到正確的HMAC等於推定的HMAC。這證明了什麼?它證明消息是由知道密鑰的實體簽名的,即它證明了消息的真實性。但是(除非只有一條消息使用此特定密鑰簽名,否則)您將無法知道自己擁有哪些簽名消息。因此,這並不能證明其完整性。[續]
-1
Dave
2014-09-27 06:45:09 UTC
view on stackexchange narkive permalink

HMAC是經常與某些數據一起發送的計算出的“簽名”。 HMAC用於驗證(驗證)數據是否已更改或替換。這是一個比喻:

您將要郵寄一個包含照片的包裹給Sarah。您希望她打開包裝並查看照片。您希望在不久的將來的某個時候,她會把包裝好的照片寄回給您。她將同一張照片放回包裝盒至關重要。您需要絕對確定她不會將更改過的照片發回給您,也不會換成其他照片。您每天都會有數百個帶有不同照片的軟件包打包出售;您永遠不會記得如此詳細的照片,以至於無法分辨出她是否做了一點改動(例如是否用噴槍從臉上噴了一個小痘痘)。

這是您可以做的:將包裹寄給她,再將照片的另一副本放在一個小鎖盒中。保持鑰匙。將帶鎖的小盒子與您郵寄給她的原始照片一起放在包裝內。假設她知道自己不打算從包裹中取出上鎖的盒子。當您從她那裡收到包裹時,將其打開,將照片放在桌子上。打開鎖盒,取出副本,比較兩者。如果它們相同,則表示她沒有更改照片(“真實”)。如果鎖中的盒子不在包裝中,或者您的鑰匙無法打開它,則假定她做錯了事,並將整個包裝丟到了垃圾箱中。這樣做的好處是,您無需“記住”您最初寄給她的東西的任何內容。確保照片合法性所需的所有內容都將返回包裝內。

在上面的示例中,小的鎖定框表示HMAC。您的密鑰是HMAC的密鑰。照片是您將HMAC應用於的數據。

以上是往返的隱喻,其中只有您有一把鑰匙。在不同的情況下,假設您經常將包裹發送給Tommy。您擔心愛管閒事的郵遞員可能會打開您的包裹並替換照片或進行更改。您對帶鎖的盒子執行相同的操作,除了在這種情況下,您要讓湯米(Tommy)擁有鑰匙的副本,以便他收到包裹時,他可以打開隨附的帶鎖的盒子並自己比較照片。如果收到後他發現照片有所不同,他的鑰匙沒有打開盒子或盒子丟失了,那麼他知道有些東西是可疑的。

上面的隱喻描述了為什麼需要HMAC,而不是它們的必要性工作。讓我們再次更改隱喻以更接近它們的工作方式:

讓我們將照片的包裝保留在心理圖像中:您想將其郵寄,然後像以前一樣再次收到,以確保照片是

在關閉包裝並郵寄之前,請先複製照片。這次沒有鎖定的盒子,而是用液體化學藥品的混合物刷滿了副本。只有您知道此混合物的配方(鍵),並且每當刷完副本時,都使用完全相同的筆觸。混合物將使照片的副本打亂並模糊成類似於現代藝術的東西。我們稱之為HMAC。您不確定完全乾燥後的樣子,但是您知道,如果使用相同的配方和相同的筆觸刷任何兩張相同的照片,則生成的HMAC看起來將相同。因此,您將乾燥的HMAC與原始照片一起放入包裝中,然後將其發送給Sarah。

從莎拉那裡拿回包裹時,包裹中包含您希望未更改的原始照片,以及您希望創建並包含的HMAC。從包裝中取出照片,進行複制,然後使用該副本創建另一個HMAC(應用混合/畫筆筆觸)。將您剛創建的HMAC與軟件包中返回的HMAC進行比較。如果它們相同,則可以確定Sarah和郵遞員沒有更改照片。

如果Sarah修改了照片,則HMAC將不相同。如果Sarah修改了HMAC,則HMAC將不相同。如果Sarah修改了照片,並嘗試創建新的HMAC,那麼HMAC將不會完全相同(她不知道您的配方)。

因此,您知道照片(數據)是否真實,這正是HMAC的用途。

謝謝。我發現您的“漩渦狀繪畫”解釋確實很有幫助。
(是的,我知道我要遲到5年。)當莎拉收到您的多張照片時,就會出現問題。她可能會給您發回錯誤的密碼,並且由於“密鑰”很常見,因此您很樂意接受。可能需要進行其他檢查,或者接受此風險。吉爾斯在上面描述了這個問題。
dtoubelis
2015-04-08 21:06:15 UTC
view on stackexchange narkive permalink

簡短的答案是“ HMAC使用對稱密鑰而不是PKI提供數字簽名”。本質上,如果您不想處理複雜的公鑰/私鑰,信任根和證書鏈,則仍可以使用HMAC獲得可靠的數字簽名。 HMAC依賴於對稱密鑰加密和預共享的機密,而不是專用/公用對。缺點與一般的對稱密鑰密碼相同-您現在需要擔心秘密密鑰的分發和保護。

謝謝,我試圖了解您將在什麼情況下使用HMAC而不是公共密鑰數字簽名方案,這似乎是一個很好的例子,說明為什麼-您不需要PKI
對稱和非對稱密鑰之間的重要區別
您的意思是HMAC不需要PKI嗎?
@PRVS是的,完全正確,HMAC不需要PKI。
sudhacker
2012-09-13 18:37:34 UTC
view on stackexchange narkive permalink

1。只要您想完整性維護數據(和真實性)

2,就可以使用HMAC。密鑰是HMAC的一部分,因為它是只有兩個參與方之間已知的共享秘密,只有他們才能創建HMAC,而沒有其他人可以創建。 (確保真實性

3。在HMAC上不可能進行長度擴展攻擊。另一方面,MAC僅將密鑰附加到消息中,這很容易受到影響。引入HMAC是為了克服對MAC的這種攻擊。

令我感到困惑的是+1,為什麼只連接消息和密鑰,以及密鑰與僅連接消息相比有什麼區別。雖然我還是很困惑。
user1187
2012-09-13 16:50:44 UTC
view on stackexchange narkive permalink
  • HMACS用於需要檢查兩個“完整性”和“真實性”的情況。例如:考慮一個向您發送一條數據及其哈希值的場景-您可以通過重新計算消息的哈希值並將其與收到的哈希值進行比較來驗證消息的完整性。但是,您不確定消息和哈希值是否由您認識/信任的人發送。如果您曾訴諸於HMACS,則可以使用只有您和受信任方知道的秘密密鑰來重新計算HMAC,並將其與您剛收到的HMAC進行比較-實際上是為了“真實性”。像我之前提到的那樣,密鑰的保密性確保了HMAC是由受信任方計算的。

  • HMACS不是鍵控哈希。當您使用鍵控哈希而不是HMACS時,可能會進行長度擴展攻擊。為了進一步閱讀,您可能想查看 this

[EDIT]

經編輯回答以下評論的答案: -“我仍然不知道為什麼密鑰在消息中?我不知道對方的公共密鑰嗎?如果我知道公共密鑰,那麼為什麼消息中的密鑰而不是我使用已知的密鑰?如果我不知道密鑰,那我為什麼要信任那個聚會?”

  • 密鑰不在消息中。密鑰是用於,用於根據消息生成HMAC。用於生成HMACS的密鑰不是任何人的“公共密鑰”。它更像是兩方之間的共享秘密。您可以查看用於AWS內容的REST API身份驗證方法,以更好地了解HMACS如何用於URL簽名。


該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...