ESP CBC模式加密算法

本備忘錄狀態

本文檔講述了一種Internet通信的標準Internet跟蹤協議,并對其改進提出了討論和建
議。請參考最新版本的"InternetOfficialProtocolStandards"(STD1)來獲得本協議的
標準化進程和狀態，此備忘錄的發布不受任何限制。

版權注意
版權歸因特網協會（1998）所有，保留一切權利。

摘要
本文檔描述了在IPSecESP（封裝安全載荷）協議中如何使用CBC（加密塊鏈接）模式的
加密算法。它不僅清楚的規定了怎樣使用某種加密算法，也規定了怎樣使用所有的CBC模式
加密算法。
目錄
1.導言 2
1.1規范要求 3
1.2知識產權聲明 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環境考慮 8
3.2密鑰源 8
4.安全考慮 8
5.參考資料 8
6.感謝 10
7.編者的地址 10
8.版權聲明 11

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

1.1規范要求
在本文檔中出現的關鍵詞“MUST”，“MUSTNOT”，“REQUIRED”，“SHOULD”，“SHOULDNOT”，
和“MAY”在[Bradner97]的描述中做了解釋。

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

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

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

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

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

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


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

2.4塊的大小和填充

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

2.5Rounds
這個變量決定了一個塊被加密多少次。然而這個變量也可以協商決定，當不使用協商解決
的時候，缺省的值必須總是存在。
+====================+============+======================+
|Algorithm|Negotiable|DefaultRounds|
+====================+============+======================+
|CAST-128|No|key<=80bits,12|
|||key>80bits,16|
+--------------------+------------+----------------------+
|RC5|No|16|
+--------------------+------------+----------------------+
|IDEA|No|8|
+--------------------+------------+----------------------+
|Blowfish|No|16|
+--------------------+------------+----------------------+
|3DES|No|48(16x3)|
+--------------------+------------+----------------------+

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

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

IDEA:
XuejiaLai和JamesMassey提出了IDEA算法（InternationalDataEncryption
Algorithm）。算法在[Lai],[Schneier]和[MOV]有詳細的描述。
IDEA算法在歐洲和美國是有專利的而在日本的專利申請還沒有批準。商業應用需要向
IDEA購買許可。
關于專利和許可信息，請參考：
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]中有關于算法的詳細描述。

3DES:
這個DES的變形，通俗的說就是“TripleDES”或是“DES-EDE3”，處理每個塊三次，每
次都使用不同的密鑰。這種使用多余一個DES過程的技術在[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]的一種簡單變形?！皁uter”鏈接技術被使用。
在DES-EDE3-CBC中，一個初始化向量（IV）和第一個64位（8字節）的明文塊（P1）進
行“XOR”運算。鍵控的DES函數被反復是使用三次，先是一次加密（EK1）然后是一次解密
（DK2）最后又是一次加密（EK3），這樣就產生了這個塊的密文。每次反復都使用互不相關的
密鑰：K1，K2，K3。
對于后續的塊，前一個加密密文塊和當前的明文塊進行“XOR”運算，鍵控的DES-EDE3
加密函數為這個塊產生密文（Ci）。
關于解密，函數的執行順序被翻轉：用K3解密，K2加密，K1解密，并和前一個密文塊進
行“XOR”運算。
注意當三個密鑰（K1，K2，K3）相同時，DES-EDE3-CBC就等同于DES-CBC。這種特性使
DES-EDE3的不用更改硬件就可以執行DES模式。

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

3.ESP載荷
ESP載荷由IV，要保護數據密文組成。因此在[Kent98]中定義的載荷區依照下面的圖表被
分割：
+---------------+---------------+---------------+---------------+
||
+初始化向量(8octets)+
||
+---------------+---------------+---------------+---------------+
||
~加密載荷(長度可變)~
||
+---------------------------------------------------------------+
12345678123456781234567812345678

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

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

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

4.安全考慮
考慮他們特殊的硬件和軟件配置，實現推薦使用他們能使用的最大長度的密鑰。注意必要
的加密在安全通道兩端產生影響，所以你不只要考慮客戶端，還要考慮服務器端。
關于使用隨機值的信息請查閱[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.感謝
本文檔是多數ESP加密算法文檔的整合。這使讀者更容易理解所有ESP算法的共同點，并
進一步的促進在ESP內使用這些算法的發展。
本文檔的內容最初是基于StephenKent先生的的意見，后面的討論則是來自IPSec郵件
列表和其他的IPSec文檔。
特別要感謝CarlisleAdams先生和PaulVanOorschot先生，他們作為技術授權對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.版權聲明
版權歸因特耐特協會所有（1998）。保留所有權利。
本文及其譯本可以提供給其他任何人，可以準備繼續進行注釋，可以繼續拷貝、出版、發
布，無論是全部還是部分，沒有任何形式的限制，不過要在所有這樣的拷貝和后續工作中提
供上述聲明和本段文字。無論如何，本文檔本身不可以做任何的修改，比如刪除版權聲明或
是關于因特耐特協會、其他的因特耐特組織的參考資料等。除了是為了開發Internet標準的
需要，或是需要把它翻譯成除英語外的其他語言的時候，在這種情況下，在Internet標準程
序中的版權定義必須被附加其中。
上面提到的有限授權允許永遠不會被Internet協會或它的繼承者或它的下屬機構廢除。
本文檔和包含在其中的信息以"Asis"提供給讀者，Internet社區和Internet工程任務
組不做任何擔保、解釋和暗示，包括該信息使用不破壞任何權利或者任何可商用性擔?；蛱?BR>定目的。