本文作用
本文為Internet提供了一種標準傳輸協議，為了進一步的改進還需要討論和提議，本文需要討
論和改進的建議。要得到規定和本協議的狀態，請參考最新版的"InternetOfficial(STD1)，本文的散布不受限制。
版權公告
Copyright(C)TheInternetSociety(1998).所有權利保留。
摘要
本文講述了HMAC算法同SHA-算法聯合作為修訂的ipSEC壓縮安全有效載荷(ESP)以及修訂
的IPSET認證報頭[AH]中作為認證機制的使用，HMAC同SHA-1結合提供了原始數據認證和安全
性保護。[Thayer97a]中提供了進一步的有關ESP和AH應用的其它信息。

目錄
1.緒論 2
2.算法和模式 2
2.1性能 2
3.密鑰原料 2
4.同ESP密碼機制的相互作用 3
5.安全考慮 3
6.致謝 3
7.參考文獻 4
8.作者地址 4

1.緒論
本文具體說明了SHA-1同HMAC結合在壓縮安全有效載荷(ESP)以及認證報頭[AH]中作為密
鑰認證機制的使用，HMAC-SHA-1-96的目的是確定數據包是可信的，沒有在傳輸中被修改過。
HMAC是一個密鑰認證算法，HMAC提供的數據完整性和數據原始性認證依靠于密鑰的分發
范圍，假如只有發送方和接收方知道密鑰，它就提供了收發方之間數據包的原始數據鑒定和完整
性檢查，假如HMAC是正確的，那就能證實是發送方發來的信息。
本文中，HMAC-SHA-1-96用在ESP和AH中，要得到進一步關于各種包括機密機制認證的
ESP是怎樣組合在一起提供安全服務的信息，可參考[ESP]和[Thayer97a]，要知道AH進一步的信
息，參考[AH]and[Thayer97a]。要害字"MUST","MUSTNOT","REQUIRED","SHALL","SHALL
NOT","SHOULD","SHOULDNOT","RECOMMENDED","MAY",和"OPTIONAL"在[RFC
2119]中介紹了。
2.算法和模式
[FIPS-180-1]講述了基本的SHA-1算法，[RFC-2104]講述了HMAC算法，HMAC算法提供了
插入不同散列算法（如SHA-1）的架構。HMAC-SHA-1-96以64位的數據分組為操作對象，補位
要求在[FIPS-180-1]非凡講述了，它也是SHA-1算法的一部分，假如你根據[FIPS-180-1]建立SHA-1，
則對HMAC-SHA-1-96來說，你就不用添加任何的補位，不需要[AH]中定義的固有信息包補位。
HMAC-SHA-1-96產生一個160位的認證值，此160位的值可以同RFC2104中描述的那樣被
縮短，要同ESP或AH一起使用，必須支持縮短的前96位值。發送時，縮短的值放在認證字段，
接收時，整個160位值都被計算出來，并同認證字段比較前96位，HMAC-SHA-1-96不支持其它
的認證值長度。選取96位是因為它是[AH]的默認認證數據長度，并且符合[RFC-2104]的要求。
2.1性能
[Bellare96a]陳述了“(HMAC)性能是散列函數的基礎”，本文中沒有關于SHA-1,HMACor或
HMAC同SHA-1結合的具體的性能分析。
[RFC-2104]中概述了一種對應用的修改，它能提高每個信息包的性能又不影響他們之間協同工
作。
3.密鑰原料
HMAC-SHA-1-96是一個密鑰算法，在[RFC-2104]中沒有指定密鑰長度，要同ESP或AH一起
使用，必須（MUST）支持160位的密鑰長度，絕對不能（MUSTNOT）支持其它長度的密鑰，也
就是說在HMAC-SHA-1-96中只能用160位的密鑰。使用160位的密鑰是因為[RFC-2104]中推薦了
（也就是低于160位的認證值會降低安全能力，高于160位的長度對安全能力的提高沒有用處）。
[RFC-2104]討論了對密鑰原料的需求，包括對好的隨機序列需求的討論。必須用一個好的偽隨
機函數來產生需要的160位的密鑰。
在寫作本文時，還沒發現一套用在HMAC中的弱的密鑰，這并不是說不存在弱的密鑰，從某
種意義上說，假如發現了一套這樣的密鑰，那么他就會被拋棄，取而代之另一套密鑰，或者一種
新的通過驗證的安全協議。
[ARCH]描述了一種當一個SA需要多個密鑰時（例如當一個ESPSA需要一個加密密鑰和一
個鑒定密鑰時）獲得密鑰原料的產生氣制。為了提供原始數據認證，密鑰分發機制必須分配的密
鑰的唯一性，并確保它們只分發給了通訊方。
關于密鑰的重新產生，[RFC-2104]推薦：最近的攻擊并沒有明確顯示需頻繁的更改密鑰，因為
這些攻擊基本上是不可行的，然而一定時間段內更新密鑰是基本的安全策略，因為這樣有助于防
止密鑰和函數潛在的虛弱性，減少密碼破譯者獲得的信息，還可限制已被截取的密碼的危害。

4.同ESP密碼機制的相互作用
到寫這篇文章時，還沒有一個出版物指出要取消HMAC-SHA-1-96算法，而代之以任何非凡
的算法。
5.安全考慮
HMAC-SHA-1-96的安全性取決于HMAC的效率，也低一些程度地取決于SHA-1的效率，在
寫這篇文章時還沒有對HMAC-SHA-1-96有用的密碼攻擊。
[RFC-2104]講敘了對“最低限度的合理的散列函數”的“生日攻擊”是行不通的，對于如
HMAC-SHA-1-96這樣的64字節的散列函數分組，對2**80個分組的成功處理的攻擊是不可行的，
除非當處理了2**30個分組時，發現潛在的散列值沖突了，一個這樣防沖突特點差的散列一般都
被認為無用的。
當SHA-1沒有發展作為一個密碼算法時，HMAC從一開始就有此標準，熟悉到這一點是很重
要的。
[RFC-2104]也討論了靠切斷散列值提供另外的安全性，強烈推薦包括HMAC的規范采用此種
切割方法。
因[RFC-2104]提供了一種HMAC組合不同散列算法的結構，那么用其它算法（如md5）代替
SHA-1是可能的，[RFC-2104]具體討論了HMAC的優勢和缺陷。
對任何密碼算法來說，它的能力部分取決于算法應用的正確性密鑰處理機制和它的應用的安
全性，關聯的秘密密鑰的強度，還取決于所有非凡系統中應用程序的強度，[RFC-2202]中提供了幫
助檢查HMAC-SHA-1-96代碼正確性的測試向量和實例程序代碼。
6.致謝
本文部分來源于JimHughes，在DES/CBC+HMAC-MD5ESP轉化方面同JimHughes一起工作
的人們，ANX參與者以及IPsec工作組的成員的先期工作。
我在此還要感謝HugoKrawczyk，他提出了對關于本文的密碼方面的內容解釋和建議。
7.參考文獻
[FIPS-180-1]NIST,FIPSPUB180-1:SecureHashStandard,
April1995.
http://csrc.nist.gov/fips/fip180-1.txt(ascii)
http://csrc.nist.gov/fips/fip180-1.ps(postscript)
[RFC-2104]Krawczyk,H.,Bellare,M.andR.Canetti,"HMAC:Keyed-
HashingforMessageAuthentication",RFC2104,February
1997.
[Bellare96a]Bellare,M.,Canetti,R.,andH.Krawczyk,"KeyingHash
FunctionsforMessageAuthentication",Advancesin
Cryptography,Crypto96Proceeding,June1996.
[ARCH]Kent,S.,andR.Atkinson,"SecurityArchitecturefor
theInternetProtocol",RFC2401,November1998.
[ESP]Kent,S.,andR.Atkinson,"IPEncapsulatingSecurity
Payload",RFC2406,November1998.
[AH]Kent,S.,andR.Atkinson,"IPAuthenticationHeader",
RFC2402,November1998.
[Thayer97a]Thayer,R.,Doraswamy,N.,andR.Glenn,"IPSecurity
DocumentRoadmap",RFC2411,November1998.
[RFC-2202]Cheng,P.,andR.Glenn,"TestCasesforHMAC-MD5and
HMAC-SHA-1",RFC2202,March1997.
[RFC-2119]Bradner,S.,"KeyWordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.
8.作者地址
CherylMadson
CiscoSystems,Inc.
EMail:cmadson@cisco.com
RobGlenn
NIST
EMail:rob.glenn@nist.gov
TheIPsecworkinggroupcanbecontactedthroughthechairs:
RobertMoskowitz
ICSA
EMail:rgm@icsa.net
TedT'so
MassachusettsInstituteofTechnology
EMail:tytso@mit.edu