本備忘錄狀態(tài)

本文檔講述了一種Internet通信的標(biāo)準(zhǔn)Internet跟蹤協(xié)議,并對其改進提出了討論和建
議。請參考最新版本的"InternetOfficial標(biāo)準(zhǔn)化進程和狀態(tài)，此備忘錄的發(fā)布不受任何限制。

版權(quán)注重
版權(quán)歸因特網(wǎng)協(xié)會（1998）所有，保留一切權(quán)利。

摘要
本文檔描述了在ipSecESP（封裝安全載荷）協(xié)議中如何使用CBC（加密塊鏈接）模式的
加密算法。它不僅清楚的規(guī)定了怎樣使用某種加密算法，也規(guī)定了怎樣使用所有的CBC模式
加密算法。
目錄
1.導(dǎo)言 2
1.1規(guī)范要求 3
1.2知識產(chǎn)權(quán)聲明 3
2.加密算法 3
2.1模式 3
2.2密鑰長度 3
2.3不健壯的密鑰 4
2.4塊的大小和填充 5
2.5Rounds 5
2.6背景 6
2.7性能 7
3.ESP載荷 7
3.1ESP環(huán)境考慮 8
3.2密鑰源 8
4.安全考慮 8
5.參考資料 8
6.感謝 10
7.編者的地址 10
8.版權(quán)聲明 11

1.導(dǎo)言
封裝安全載荷（ESP）[Kent98]為IP數(shù)據(jù)包提供機密性，來保護加密的載荷數(shù)據(jù)。本規(guī)范
描述了在ESP中使用CBC模式的加密算法。
而本文檔沒有描述使用缺省加密算法DES，讀者應(yīng)該熟悉相關(guān)文檔。[Madson98]
假定讀者熟悉在“因特耐特協(xié)議安全體系結(jié)構(gòu)”[Atkinson95]，“IP安全文檔索引”
[Thayer97]和“IP封裝安全載荷（ESP）”[Kent98]文檔中描述的相關(guān)術(shù)語和定義。
而且本文檔和[Kent98]是相關(guān)的，必須聯(lián)系它的上下文來閱讀。

1.1規(guī)范要求
在本文檔中出現(xiàn)的要害詞“MUST”，“MUSTNOT”，“REQUIRED”，“SHOULD”，“SHOULDNOT”，
和“MAY”在[Bradner97]的描述中做了解釋。

1.2知識產(chǎn)權(quán)聲明
關(guān)于知識產(chǎn)權(quán)的有效性和范圍，使用本文檔描述的技術(shù)的權(quán)利，或是其他可使用與否的權(quán)
利的許可等
，IETF不堅持自己的立場。它也沒有對確定這些權(quán)利所做的努力有任何異議。關(guān)于ITIF在
跟蹤標(biāo)準(zhǔn)和相
關(guān)標(biāo)準(zhǔn)文檔中考慮這些權(quán)利的信息可以在BCP-11中找到。有關(guān)的出版和授權(quán)有效等，用戶可
以從IETF秘書
處獲得。

2.加密算法
所有的對稱塊加密算法都共享公用的特點和變量。包括模式，密鑰大小，不健壯的密鑰，
塊的大小和Rounds，所有的這些都在下邊做了解釋。

本文檔舉例說明了某種加密算法，象Blowfish[Schneier93],CAST-128[Adams97],3DES,
IDEA[Lai][MOV],和RC5[Baldwin96]和其他任何可以和ESP一起使用的塊加密算法，只要
他們使用的所有變量都包括在本文檔清楚定義的范圍內(nèi)。

2.1模式
所有在本文檔中描述或涉及的對稱塊加密算法都使用加密塊鏈接（BCB）模式。這種模式
的算法需要一個和塊的長度一樣大小的初始化向量（IV）。使用一個隨機產(chǎn)生的IV，防止完
全一致的和加密算法塊尺寸一樣長度的第一個明文數(shù)據(jù)塊產(chǎn)生完全一致的密文。
在數(shù)據(jù)加密之前，IV和第一個明文塊進行XOR運算。然后對于連續(xù)的塊，在當(dāng)前的明文
塊加密之前，先和前一個密文塊進行一次XOR運算。
更多的關(guān)于CBC模式的信息可以在[Schneier95]中找到。

2.2密鑰長度
一些加密算法答應(yīng)使用可變長度的密鑰，而另一些只答應(yīng)特定長度的密鑰。密鑰的長度是
和算法的健壯性想關(guān)聯(lián)的，因此較長的密鑰總是比較短的密鑰難于被攻擊。
本文檔規(guī)定所有的密鑰長度必須是8位的整數(shù)倍。
本文檔沒有為每個加密算法指定缺省的密鑰長度。密鑰的長度由算法的顧問專家和考慮算
法性能的健壯性來決定。
+==============+==================+=================+==========+
AlgorithmKeySizes(bits)PopularSizesDefault
+==============+==================+=================+==========+
CAST-128[1]40to12840,64,80,128128
+--------------+------------------+-----------------+----------+
RC540to204040,128,160128
+--------------+------------------+-----------------+----------+
IDEA128128128
+--------------+------------------+-----------------+----------+
Blowfish40to448128128
+--------------+------------------+-----------------+----------+
3DES[2]192192192
+--------------+------------------+-----------------+----------+
注：[1]對于CAST-128，因為CAST-128的密鑰計劃假設(shè)一個輸入密鑰是128位的，所以
密鑰少于128位時，必須在最右邊填充0或是多于128位時，取重要的128位。假如你有一
個80位長的密鑰“3B5D831CFE”，就應(yīng)該進行填充處理使其成為一個128位的密鑰
“3B5D831CFE000000”。
[2]第一個3DES密鑰來自第一個64位，第二個密鑰來自下一個64位，第三個密鑰來
自最后64位。在開始接受一套新的密鑰的時候，實現(xiàn)必須考慮奇偶校驗位。三個密鑰中的每
一個是實際長度是56位，包括額外的8位用做奇偶校驗。
讀者應(yīng)該注重到所有上面提到的加密算法的最小密鑰長度是40位長，編者強烈的建
議實現(xiàn)時不要使用短于40位的密鑰。

2.3不健壯的密鑰
應(yīng)該對不健壯的密鑰進行檢查。假如這樣的密鑰被發(fā)現(xiàn)，這個密鑰應(yīng)該被拒絕，并發(fā)出新
的SA請求。一些算法有一定不能被使用的不健壯的密鑰或是本質(zhì)上是不健壯的密鑰。
新的不健壯密鑰可能被發(fā)現(xiàn)，所以對于這些算法，本文檔不可能包括所有可能的不健壯密
鑰。請查看其他的密碼源資料，比如[MOV]和[Schneier]，來獲知更多的不健壯密鑰。


CAST-128:
沒有已知的不健壯密鑰。
RC5:
當(dāng)使用16rounds時，沒有已知的不健壯密鑰。
IDEA:
IDEA已經(jīng)被發(fā)現(xiàn)存在不健壯密鑰，請查看[MOV]和[Schneier]來獲得更多的相關(guān)信息。
Blowfish:
對于Blowfish算法也發(fā)現(xiàn)了不健壯密鑰。不健壯密鑰就是那些對于特定的S-box產(chǎn)生完
全一致的輸入的密鑰。
不幸的是，在S-box值產(chǎn)生之前，，沒有辦法對不健壯密鑰進行測試。無論如何，隨機產(chǎn)
生這樣一個密鑰的機會是很小的。
3DES:
DES有64個已知的不健壯密鑰，包括所謂的semi-weak密鑰和possibly-weak密鑰
[Schneier95,pp280-282]。
而隨機的產(chǎn)生一個這樣的密鑰的可能性是可以忽略的。
對于DES-EDE3，沒有已知的需要拒絕的不健壯或補充的密鑰。由于使用了多個密鑰，任
何的不健壯性都被排除了。
無論如何，假如前兩個或是后兩個獨立的64位密鑰是相同的（k1==k2或k2==k3），
那么3DES就和DES完全一樣了。實現(xiàn)者必須拒絕使用有這種屬性的密鑰。

2.4塊的大小和填充

所有在本文檔中描述的算法都使用8個8位組（64位）的塊。
在排列載荷類型和填充長度8位組（在[Kent98]中有定義）時要使用填充。填充部分必須
完全的排列數(shù)據(jù)
使它滿足8個8位組（64位）的加密邊界要求。

2.5Rounds
這個變量決定了一個塊被加密多少次。然而這個變量也可以協(xié)商決定，當(dāng)不使用協(xié)商解決
的時候，缺省的值必須總是存在。
+====================+============+======================+
AlgorithmNegotiableDefaultRounds
+====================+============+======================+
CAST-128Nokey<=80bits,12
key>80bits,16
+--------------------+------------+----------------------+
RC5No16
+--------------------+------------+----------------------+
IDEANo8
+--------------------+------------+----------------------+
BlowfishNo16
+--------------------+------------+----------------------+
3DESNo48(16x3)
+--------------------+------------+----------------------+

2.6背景
CAST-128:
CAST設(shè)計程序最初是由CarlisleAdams和StaffordTavares在Queen大學(xué)（位于加拿
大的安大略省的Kingston）提出的，后來的改進工作由CarlisleAdams和MichaelWiener
用了幾年時間完成。CAST-128是在[Adams97]中應(yīng)用CAST設(shè)計程序作為大綱的結(jié)果。

RC5:
RC5加密算法是由RonRivest為RSA數(shù)據(jù)安全公司開發(fā)的。為了滿足更高的加密軟硬件
性能要求，還是選擇DES。RC5是有專利的（pat.no.5,724,428）。關(guān)于RC5的描述可以在[MOV]
和[Schneier]中找到。

IDEA:
XuejiaLai和JamesMassey提出了IDEA算法（InternationalDataEncryption
Algorithm）。算法在[Lai],[Schneier]和[MOV]有具體的描述。
IDEA算法在歐洲和美國是有專利的而在日本的專利申請還沒有批準(zhǔn)。商業(yè)應(yīng)用需要向
IDEA購買許可。
關(guān)于專利和許可信息，請參考：
AscomSystecAG,Dept.CMVV
Gewerbepark,CH-5506
Magenwil,Switzerland
Phone:+4164565983
Fax:+4164565990
idea@ascom.ch
http://www.ascom.ch/Web/systec/policy/normal/exhibit1.Html

Blowfish:
BrUCeSchneier提出了Blowfish塊加密算法。在[Schneier93],[Schneier95]和
[Schneier]中有關(guān)于算法的具體描述。

3DES:
這個DES的變形，通俗的說就是“TripleDES”或是“DES-EDE3”，處理每個塊三次，每
次都使用不同的密鑰。這種使用多余一個DES過程的技術(shù)在[Tuchman79]被中提議的。

P1P2Pi

IV->->(X)+>->->->(X)+>->->->(X)
v^v^v
+-----+^+-----+^+-----+
k1->E^k1->E^k1->E
+-----+^+-----+^+-----+
^^
v^v^v
+-----+^+-----+^+-----+
k2->D^k2->D^k2->D
+-----+^+-----+^+-----+
^^
v^v^v
+-----+^+-----+^+-----+
k3->E^k3->E^k3->E
+-----+^+-----+^+-----+
^^
+>->->++>->->++>->->

C1C2Ci

DES-EDE3-CBC算法是DES-CBC算法[FIPS-46]的一種簡單變形。“outer”鏈接技術(shù)被使用。
在DES-EDE3-CBC中，一個初始化向量（IV）和第一個64位（8字節(jié)）的明文塊（P1）進
行“XOR”運算。鍵控的DES函數(shù)被反復(fù)是使用三次，先是一次加密（EK1）然后是一次解密
（DK2）最后又是一次加密（EK3），這樣就產(chǎn)生了這個塊的密文。每次反復(fù)都使用互不相關(guān)的
密鑰：K1，K2，K3。
對于后續(xù)的塊，前一個加密密文塊和當(dāng)前的明文塊進行“XOR”運算，鍵控的DES-EDE3
加密函數(shù)為這個塊產(chǎn)生密文（Ci）。
關(guān)于解密，函數(shù)的執(zhí)行順序被翻轉(zhuǎn)：用K3解密，K2加密，K1解密，并和前一個密文塊進
行“XOR”運算。
注重當(dāng)三個密鑰（K1，K2，K3）相同時，DES-EDE3-CBC就等同于DES-CBC。這種特性使
DES-EDE3的不用更改硬件就可以執(zhí)行DES模式。

2.7性能
關(guān)于比較評估這些或是其他加密算法的運行速度的表，請查看[Schneier97]或是關(guān)于最新
的性能比較請查看[Bosseleaers]。

3.ESP載荷
ESP載荷由IV，要保護數(shù)據(jù)密文組成。因此在[Kent98]中定義的載荷區(qū)依照下面的圖表被
分割：
+---------------+---------------+---------------+---------------+

+初始化向量(8octets)+

+---------------+---------------+---------------+---------------+

~加密載荷(長度可變)~

+---------------------------------------------------------------+
12345678123456781234567812345678

IV區(qū)域必須和使用的加密算法要求的塊的長度相同。IV必須被隨機選擇。公認(rèn)的習(xí)慣是
使用隨機數(shù)據(jù)作為第一個IV，來自一個加密處理過程的最后的加密數(shù)據(jù)塊作為下一個加密處
理過程的IV。
在每個數(shù)據(jù)包中包含IV確保了可以對每個接收到的數(shù)據(jù)包進行解密處理，即使一些數(shù)據(jù)
包在傳輸過程中分段或是重組。
為了避免在不同的包中，ECB加密非常相似的明文，實現(xiàn)時一定不能使用計數(shù)器或是低
hamming的距離源作為IV。

3.1ESP環(huán)境考慮
當(dāng)前在這些算法和ESP的其他方面之間還沒有關(guān)于交互作用的已知出版物。比如使用某種
驗證摘要。

3.2密鑰源
從密鑰交換協(xié)議向ESP算法發(fā)出的最少位數(shù)一定要大于或等于這個密鑰的長度。
加密器的加密和解密密鑰來自密鑰源的前<x>位，<x>又密鑰長度的需要決定。

4.安全考慮
考慮他們非凡的硬件和軟件配置，實現(xiàn)推薦使用他們能使用的最大長度的密鑰。注重必要
的加密在安全通道兩端產(chǎn)生影響，所以你不只要考慮客戶端，還要考慮服務(wù)器端。
關(guān)于使用隨機值的信息請查閱[Bell97]。
對于更多的安全考慮，推薦讀者閱讀描述實際的加密算法的文檔。

5.參考資料

[Adams97]Adams,C,"TheCAST-128EncryptionAlgorithm",
RFC2144,1997.

[Atkinson98]Kent,S.andR.Atkinson,"SecurityArchitectureforthe
InternetProtocol",RFC2401,November1998.

[Baldwin96]Baldwin,R.andR.Rivest,"TheRC5,RC5-CBC,RC5-CBC-
Pad,andRC5-CTSAlgorithms",RFC2040,October1996.

[Bell97]S.Bellovin,"ProbablePlaintextCryptanalysisoftheIP
SecurityProtocols",ProceedingsoftheSymposiumon
NetworkandDistributedSystemSecurity,SanDiego,CA,
pp.155-160,February1997(also
http://www.research.att.com/~smb/proBTxt.{ps,pdf}).

[Bosselaers]A.Bosselaers,"PerformanceofPentiumimplementations",
http://www.esat.kuleuven.ac.be/~bosselae/

[Bradner97]Bradner,S.,"KeyWordsforuseinRFCstoindicate
RequirementLevels",BCP14,RFC2119,March1997.

[Crypto93]J.Daemen,R.Govaerts,J.Vandewalle,"WeakKeysfor
IDEA",AdvancesinCryptology,CRYPTO93Proceedings,
Springer-Verlag,pp.224-230.

[FIPS-46]USNationalBureauofStandards,"DataEncryption
Standard",FederalInformationProcessingStandard(FIPS)
Publication46,January1977.

[Kent98]Kent,S.andR.Atkinson,"IPEncapsulatingSecurity
Payload(ESP)",RFC2406,November1998.

[Lai]X.Lai,"OntheDesignandSecurityofBlockCiphers",
ETHSeriesinInformationProcessing,v.1,Konstanz:
Hartung-GorreVerlag,1992.

[Madson98]Madson,C.andN.Dorswamy,"TheESPDES-CBCCipher
AlgorithmWithEXPlicitIV",RFC2405,November1998.

[MOV]A.Menezes,P.VanOorschot,S.Vanstone,"HandbooKOF
AppliedCryptography",CRCPress,1997.ISBN0-8493-
8523-7

[Schneier]B.Schneier,"AppliedCryptographySecondEdition",John
Wiley&Sons,NewYork,NY,1995.ISBN0-471-12845-7
[Schneier93]B.Schneier,"DescriptionofaNewVariable-LengthKey,
64-BitBlockCipher",from"FastSoftwareEncryption,
CambridgeSecurityWorkshopProceedings",Springer-
Verlag,1994,pp.191-204.
http://www.counterpane.com/bfsverlag.html

[Schneier95]B.Schneier,"TheBlowfishEncryptionAlgorithm-One
YearLater",Dr.Dobb'sJournal,September1995,
http://www.counterpane.com/bfdobsoyl.html

[Schneier97]B.Scheier,"SpeedComparisonsofBlockCiphersona
Pentium."February1997,
http://www.counterpane.com/speed.html

[Thayer97]Thayer,R.,Doraswamy,N.andR.Glenn,"IPSecurity
DocumentRoadmap",RFC2411,November1998.

[Tuchman79]Tuchman,W,"HellmanPresentsNoShortcutSolutionsto
DES",IEEESpectrum,v.16n.7,July1979,pp.40-41.

6.感謝
本文檔是多數(shù)ESP加密算法文檔的整合。這使讀者更輕易理解所有ESP算法的共同點，并
進一步的促進在ESP內(nèi)使用這些算法的發(fā)展。
本文檔的內(nèi)容最初是基于StephenKent先生的的意見，后面的討論則是來自IPSec郵件
列表和其他的IPSec文檔。
非凡要感謝CarlisleAdams先生和PaulVanOorschot先生，他們作為技術(shù)授權(quán)對CAST
提供了輸入和評論。
感謝所有先前ESP3DES文檔的編者們，他們是W.Simpson，N.Doraswamy，P.Metzger
和P.Karn。
感謝BrettHoward，他對ESP-RC5最初的工作提供了幫助。
感謝Markku-JuhaniSaarinen，HelgerLipmaa和BartPreneel，他們對IDEA和其他的
算法提供的輸入。

7.編者的地址
RoyPereira
TimeStepCorporation

Phone:+1(613)599-3610x4808
EMail:rpereira@timestep.com


RobAdams
CiscoSystemsInc.

Phone:+1(408)457-5397
EMail:adams@cisco.com


Contributors:

RobertW.Baldwin
RSADataSecurity,Inc.

Phone:+1(415)595-8782
EMail:baldwin@rsa.comorbaldwin@lcs.mit.edu


GregCarter
EntrustTechnologies

Phone:+1(613)763-1358
EMail:carterg@entrust.com


RodneyThayer
SableTechnologyCorporation

Phone:+1(617)332-7292
EMail:rodney@sabletech.com

可以通過IPSec工作組的郵件列表(ipsec@tis.com)或是它的講座，來連接
(ipsec@tis.com)工作組。
RobertMoskowitz
InternationalComputerSecurityAssociation

EMail:rgm@icsa.net

TheodoreY.Ts'o
MassachusettsInstituteofTechnology

EMail:tytso@MIT.EDU

8.版權(quán)聲明
版權(quán)歸因特耐特協(xié)會所有（1998）。保留所有權(quán)利。
本文及其譯本可以提供給其他任何人，可以預(yù)備繼續(xù)進行注釋，可以繼續(xù)拷貝、出版、發(fā)
布，無論是全部還是部分，沒有任何形式的限制，不過要在所有這樣的拷貝和后續(xù)工作中提
供上述聲明和本段文字。無論如何，本文檔本身不可以做任何的修改，比如刪除版權(quán)聲明或
是關(guān)于因特耐特協(xié)會、其他的因特耐特組織的參考資料等。除了是為了開發(fā)Internet標(biāo)準(zhǔn)的
需要，或是需要把它翻譯成除英語外的其他語言的時候，在這種情況下，在Internet標(biāo)準(zhǔn)程
序中的版權(quán)定義必須被附加其中。
上面提到的有限授權(quán)答應(yīng)永遠不會被Internet協(xié)會或它的繼續(xù)者或它的下屬機構(gòu)廢除。
本文檔和包含在其中的信息以"Asis"提供給讀者，Internet社區(qū)和Internet工程任務(wù)
組不做任何擔(dān)保、解釋和暗示，包括該信息使用不破壞任何權(quán)利或者任何可商用性擔(dān)保或特
定目的。