密鑰交換演算法視頻

『壹』 RSA  加密演算法（原理篇）

前幾天看到一句話，「我們中的很多人把一生中最燦爛的笑容大部分都獻給了手機和電腦屏幕」。心中一驚，這說明了什麼？手機和電腦已經成為了我們生活中的一部分，所以才會有最懂你的不是你，也不是你男朋友，而是大數據。

如此重要的個人數據，怎樣才能保證其在互聯網上的安全傳輸呢？當然要靠各種加密演算法。說起加密演算法，大家都知道有哈希、對稱加密和非對稱加密了。哈希是一個散列函數，具有不可逆操作；對稱加密即加密和解密使用同一個密鑰，而非對稱加密加密和解密自然就是兩個密鑰了。稍微深入一些的，還要說出非對稱加密演算法有DES、3DES、RC4等，非對稱加密演算法自然就是RSA了。那麼當我們聊起RSA時，我們又在聊些什麼呢？今天筆者和大家一起探討一下，有不足的地方，還望各位朋友多多提意見，共同進步。

RSA簡介：1976年由麻省理工學院三位數學家共同提出的，為了紀念這一里程碑式的成就，就用他們三個人的名字首字母作為演算法的命名。即 羅納德·李維斯特 （Ron Rivest）、 阿迪·薩莫爾 （Adi Shamir）和 倫納德·阿德曼 （Leonard Adleman）。

公鑰：用於加密，驗簽。

私鑰：解密，加簽。

通常知道了公鑰和私鑰的用途以後，即可滿足基本的聊天需求了。但是我們今天的主要任務是來探究一下RSA加解密的原理。

說起加密演算法的原理部分，肯定與數學知識脫不了關系。

我們先來回憶幾個數學知識：

φn = φ(A*B)=φ(A)*φ(B)=(A-1)*(B-1)。

這個公式主要是用來計算給定一個任意的正整數n，在小於等於n的正整數中，有多少個與n構成互質的關系。

其中n=A*B，A與B互為質數，但A與B本身並不要求為質數，可以繼續展開，直至都為質數。

在最終分解完成後，即 φ(N) = φ(p1)*φ(p2)*φ(p3)... 之後，p1，p2，p3都是質數。又用到了歐拉函數的另一個特點，即當p是質數的時候，φp = p - 1。所以有了上面給出的歐拉定理公式。

舉例看一下：

計算15的歐拉函數，因為15比較小，我們可以直接看一下，小於15的正整數有 1、2、3、4、5、6、7、8、9、10、11、12、13、14。和15互質的數有1、2、4、7、8、11、13、14一共四個。

對照我們剛才的歐拉定理： 。

其他感興趣的，大家可以自己驗證。

之所以要在這里介紹歐拉函數，我們在計算公鑰和私鑰時候，會用到。

如果兩個正整數m 和 n 互質，那麼m 的 φn 次方減1，可以被n整除。

 其中  .

其中當n為質數時，那麼  上面看到的公式就變成了

 mod n   1.

這個公式也就是著名的 費馬小定理 了。

如果兩個正整數e和x互為質數，那麼一定存在一個整數d，不止一個，使得 e*d - 1 可以被x整除，即 e * d mode x   1。則稱 d 是 e 相對於 x的模反元素。

了解了上面所講的歐拉函數、歐拉定理和模反元素後，就要來一些化學反應了，請看圖：

上面這幅圖的公式變化有沒有沒看明白的，沒看明白的咱們評論區見哈。

最終我們得到了最重要的第5個公式的變形，即紅色箭頭後面的：

 mod n   m。

其中有幾個關系，需要搞明白，m 與 n 互為質數，φn = x，d 是e相對於x的模反元素。

有沒有看到一些加解密的雛形。

從 m 到 m。 這中間涵蓋了從加密到解密的整個過程，但是缺少了我們想要的密文整個過程。

OK，下面引入本文的第四個數學公式：

我們來看一下整個交換流程：

1、客戶端有一個數字13，服務端有一個數字15;

2、客戶端通過計算 3的13次方 對 17 取余，得到數字12; 將12發送給服務端；同時服務端通過計算3的15次方，對17取余，得到數字6，將6發送給客戶端。至此，整個交換過程完成。

3、服務端收到數字12以後，繼續計算，12的15次方 對 17取余，得到 數字10。

4、客戶端收到數字 6以後，繼續計算，6的13次方 對 17 取余，得到數字 10。

有沒有發現雙方，最終得到了相同的內容10。但是這個數字10從來沒有在網路過程中出現過。

好，講到這里，可能有些人已經恍然大悟，這就是加密過程了，但是也有人會產生疑問，為什麼要取數字3 和 17 呢，這里還牽涉到另一個數學知識，原根的問題。即3是17的原根。看圖

有沒有發現規律，3的1~16次方，對17取余，得到的整數是從1~16。這時我們稱3為17的原根。也就是說上面的計算過程中有一組原根的關系。這是最早的迪菲赫爾曼秘鑰交換演算法。

解決了為什麼取3和17的問題後，下面繼續來看最終的RSA是如何產生的：

還記得我們上面提到的歐拉定理嗎，其中 m 與 n 互為質數，n為質數，d 是 e 相對於 φn的模反元素。

當迪菲赫爾曼密鑰交換演算法碰上歐拉定理會產生什麼呢？

我們得到下面的推論：

好，到這里我們是不是已經看到了整個的加密和解密過程了。

其中 m 是明文；c 是密文； n 和 e 為公鑰；d 和 n 為私鑰 。

其中幾組數字的關系一定要明確：

1、d是e 相對於 φn 的模反元素，φn = n-1，即 e * d mod n = 1.

2、m 小於 n，上面在講迪菲赫爾曼密鑰交換演算法時，提到原根的問題，在RSA加密演算法中，對m和n並沒有原根條件的約束。只要滿足m與n互為質數，n為質數，且m < n就可以了。

OK，上面就是RSA加密演算法的原理了，經過上面幾個數學公式的狂轟亂炸，是不是有點迷亂了，給大家一些時間理一下，後面會和大家一起來驗證RSA演算法以及RSA為什麼安全。

『貳』 如何描述RSA密鑰交換演算法

密鑰交換演算法中講到的密鑰都是一般指對稱加密演算法的密鑰（注意區別：非對稱演算法自己本身的密鑰），因為對於對稱演算法的特性來說，採取」一次一密」的話才比較安全。

RSA，可以用做密鑰傳輸演算法，即使用對端的RSA公鑰對密鑰進行加密，對端使用自己的私鑰對其進行解密，就可以獲取密鑰。

RSA密鑰生成步驟:

『叄』 常見密碼演算法原理

PBKDF2(Password-Based Key Derivation Function)是一個用來導出密鑰的函數，用來生成加密的密碼，增加破解的難度，類似bcrypt/scrypt等，可以用來進行密碼或者口令的加密存儲。主要是鹽值+pwd，經過多輪HMAC演算法的計算，產生的密文。
PBKDF2函數的定義
DK = PBKDF2(PRF, Password, Salt, c, dkLen)
• PRF是一個偽隨機函數，例如HASH_HMAC函數，它會輸出長度為hLen的結果。
• Password是用來生成密鑰的原文密碼。
• Salt是一個加密用的鹽值。
• c是進行重復計算的次數。
• dkLen是期望得到的密鑰的長度。
• DK是最後產生的密鑰。
https://segmentfault.com/a/1190000004261009

下面我們以Alice和Bob為例敘述Diffie-Hellman密鑰交換的原理。
1,Diffie-Hellman交換過程中涉及到的所有參與者定義一個組，在這個組中定義一個大質數p，底數g。
2,Diffie-Hellman密鑰交換是一個兩部分的過程，Alice和Bob都需要一個私有的數字a，b。
下面是DH交換的過程圖：
本圖片來自wiki
下面我們進行一個實例
1.愛麗絲與鮑伯協定使用p=23以及g=5.
2.愛麗絲選擇一個秘密整數a=6, 計算A = g^a mod p並發送給鮑伯。
A = 5^6 mod 23 = 8.
3.鮑伯選擇一個秘密整數b=15, 計算B = g^b mod p並發送給愛麗絲。
B = 5^15 mod 23 = 19.
4.愛麗絲計算s = B a mod p
19^6 mod 23 = 2.
5.鮑伯計算s = A b mod p
8^15 mod 23 = 2.

ECDH:
ECC演算法和DH結合使用，用於密鑰磋商，這個密鑰交換演算法稱為ECDH。交換雙方可以在不共享任何秘密的情況下協商出一個密鑰。ECC是建立在基於橢圓曲線的離散對數問題上的密碼體制，給定橢圓曲線上的一個點P，一個整數k，求解Q=kP很容易；給定一個點P、Q，知道Q=kP，求整數k確是一個難題。ECDH即建立在此數學難題之上。密鑰磋商過程：
假設密鑰交換雙方為Alice、Bob，其有共享曲線參數（橢圓曲線E、階N、基點G）。

來自 http://www.cnblogs.com/fishou/p/4206451.html

https://zh.wikipedia.org/wiki/SHA%E5%AE%B6%E6%97%8F

exponent1 INTEGER, -- d mod (p-1)
exponent2 INTEGER, -- d mod (q-1)
coefficient INTEGER, -- (inverse of q) mod p
otherPrimeInfos OtherPrimeInfos OPTIONAL
}
-----END RSA PRIVATE KEY-----
while a RSA public key contains only the following data:
-----BEGIN RSA PUBLIC KEY-----
RSAPublicKey ::= SEQUENCE {
molus INTEGER, -- n
publicExponent INTEGER -- e
}
-----END RSA PUBLIC KEY-----
and this explains why the private key block is larger.
Note that a more standard format for non-RSA public keys is
-----BEGIN PUBLIC KEY-----
PublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
PublicKey BIT STRING
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
}
-----END PUBLIC KEY-----
More info here.
BTW, since you just posted a screenshot of the private key I strongly hope it was just for tests :)

密鑰的長度
C:\herong>java RsaKeyGenerator 128
p: 17902136406704537069
q: 17902136406704537077
m:
Molus:
Key size: 128
Public key:
Private key:
C:\herong>java RsaKeyGenerator 256
p:
q:
m: ...
Molus: ...
Key size: 256
Public key: ...
Private key: ...

https://security.stackexchange.com/questions/90169/rsa-public-key-and-private-key-lengths
https://stackoverflow.com/questions/2921508/trying-to-understand-java-rsa-key-size >

http://www.herongyang.com/Cryptography/RSA-BigInteger-Keys-Generated-by-RsaKeyGenerator-java.html

update() adds data to the Cipher』s internal buffer, then returns all currently completely encoded blocks. If there are any encoded blocks left over, they remain in the Cipher』s buffer until the next call, or a call to doFinal(). This means that if you call update() with a four byte array to encrypt, and the buffer size is eight bytes, you will not receive encoded data on the return (you』ll get a null instead). If your next call to update() passes five bytes of data in, you will get an 8 byte (the block size) array back, containing the four bytes passed in on the previous call, the first four bytes from the current call – the remaining byte from the current call is left in the Cipher』s buffer.
doFinal() on the other hand is much simpler: it encrypts the passed data, pads it out to the necessary length, and then returns it. The Cipher is essentially stateless.

來自 https://segmentfault.com/a/1190000006931511

DH演算法的中間人攻擊
在最初的描述中，迪菲－赫爾曼密鑰交換本身並沒有提供通訊雙方的身份驗證服務，因此它很容易受到中間人攻擊。 一個中間人在信道的中央進行兩次迪菲－赫爾曼密鑰交換，一次和Alice另一次和Bob，就能夠成功的向Alice假裝自己是Bob，反之亦然。而攻擊者可以解密（讀取和存儲）任何一個人的信息並重新加密信息，然後傳遞給另一個人。因此通常都需要一個能夠驗證通訊雙方身份的機制來防止這類攻擊。

優缺點：
1、 僅當需要時才生成密鑰，減小了將密鑰存儲很長一段時間而致使遭受攻擊的機會。
2、 除對全局參數的約定外，密鑰交換不需要事先存在的基礎結構。
然而，該技術也存在許多不足：
1、 沒有提供雙方身份的任何信息。
2、 它是計算密集性的，因此容易遭受阻塞性攻擊，即對手請求大量的密鑰。受攻擊者花費了相對多的計算資源來求解無用的冪系數而不是在做真正的工作。
3、 沒辦法防止重演攻擊。
4、 容易遭受中間人的攻擊。第三方C在和A通信時扮演B；和B通信時扮演A。A和B都與C協商了一個密鑰，然後C就可以監聽和傳遞通信量。中間人的攻擊按如下進行：
（1） B在給A的報文中發送他的公開密鑰。
（2） C截獲並解析該報文。C將B的公開密鑰保存下來並給A發送報文，該報文具有B的用戶ID但使用C的公開密鑰YC，仍按照好像是來自B的樣子被發送出去。A收到C的報文後，將YC和B的用戶ID存儲在一塊。類似地，C使用YC向B發送好像來自A的報文。
（3） B基於私有密鑰XB和YC計算秘密密鑰K1。A基於私有密鑰XA和YC計算秘密密鑰K2。C使用私有密鑰XC和YB計算K1，並使用XC和YA計算K2。
（4） 從現在開始，C就可以轉發A發給B的報文或轉發B發給A的報文，在途中根據需要修改它們的密文。使得A和B都不知道他們在和C共享通信。

『肆』 IKE密鑰交換原理

在採用IKE動態協商方式建立IPSec隧道時，SA有兩種：一種IKE SA,另一種是IPSec SA。建立IKE SA目的是為了協商用於保護IPSec隧道的一組安全參數，建立IPSec SA的目的是為了協商用於保護用戶數據的安全參數，但在IKE動態協商方式中，IKE SA是IPSec SA的基礎，因為IPSec SA的建立需要用到IKE SA建立後的一系列密鑰。

手工方式建立SA存在配置復雜、不支持發起方地址動態變化、 建立的SA永不老化、不利於安全性等缺點。本節具體介紹動態協商方式的好處,以及IKE與IPSec的關系。

（1） 降低了配置的復雜度, 在IKE動態協商方式下，SPI, 認證密鑰和加密密鑰等參數將自動生成，而手工方式中需根據SA出方向和入方向分別指定。

（2） 提供抗重放功能, IPSec使用AH或ESP報頭中的序列號實現抗重放(不接受序列號相同的數據包)。當AH或ESP報頭中的序列號溢出（也是達到了最大值，不能再繼續往下編 號，要開始新一輪的重新編號了）後，為實現抗重放，SA需要重新建立，這個過程需要IKE協議的配合，所以手工方式下不支持抗重放功能。

（3）支持協商發起方地址動態變化情況下（如採用PPP。E撥號方式接入Internet）的身份認證，手工方式不支持，只能適用於在兩端都採用專線連接方式接入Internet情形。

（4）支持認證中心CA （Certificate Authority）在線對對等體身份的認證和集中管理，有利於IPSec的大規模部署，手工方式不支持在線認證方式。

（5）通過IKE協商建立的SA具有生存周期，可以實時更新，降低了SA被破解的風險，提高了安全性。

生存周期到達指定的時間或指定的流量，SA就會失效。在SA快要失效前，IKE將為對等體協商新的SA。在新的SA協商好之後，對等體立即採用新的SA保護通信。生存周期有兩種定義方式：

IKE 協議建立在 ISAKMP （Internet Security Association and Key Management Pr otocol, Internet安全聯盟和密鑰管理協議）定義的框架上，是基於UDP的應用層協議（對應UDP500埠. 它為IPSec提供了自動協商交換密鑰、建立SA的服務，能夠簡化IPSec的使用和管理。

其實IKE也不是一個單獨的協議，它包括三大協議：ISAKMP （Internet Security Association and Key Management Protocol,網際網路安全聯盟和密鑰管理協議），Oakley （Oakley Key Determination Protocol,奧利克密鑰確定協議）和SKEME （Sec ure Key Exchange Mechanism for Internet,網際網路安全密鑰交換機制）。ISAKMP主 要定義了IKE對等體（IKE Peer）之間合作關系，建立IKE SA。OakLey協議是一個產生和交換IPSec密鑰材料並協調IPSec參數的框架（包括支持哪些安全協議）；SKEM E協議決定了IKE密鑰交換的方式，主要採用DH （Diffie-Hellman）演算法。

IKE與IPSec （包括AH和ESP協議）的關系如下圖所示，IKE是UDP之上的一個 應用層協議（AH和ESP是網路層協議），是IPSec的信令協議；IKE為IPSec協商建立 SA,並把建立的參數及生成的密鑰交給IPSec; IPSec使用IKE建立的SA對IP報文加密 或認證處理。

對等體之間建立一個IKE SA後，在IKE SA保護了IPSec隧道的情況下，再根據配置的AH、ESP安全協議等參數協商出一對IPSec SA,用於對等體間的數據在IPSec隧道中的安全數據傳輸。

IKE協議目前有IKEv1和IKEv2兩個版本。IKEv1版本使用兩個階段為IPSec進行密 鑰協商並最終建立IPSec SA。第一階段，通信雙方協商建立IKE本身使用的安全通道 （即隧道），即建立一對IKE SA。第二階段，利用這個已通過了認證和安全保護的安全通道建立一對用於保護隧道中數據安全傳輸的IPSec SA。而IKEv2版本則簡化了協商過程，在一次協商中可直接產生IPSec的密鑰，生成IPSec SA。

下面先來了解IKE在產生SA （包括IKE SA和IPSec SA）的過程中所用的一些安全機制，這是後面介紹具體的IKE協商過程中所要用到的。

IPSec應用方案之所以能在公網（如Internet）上安全地進行網路通信，其重要原因是可在對等體間的整個隧道建立和數據傳輸過程中均有各種安全機制來做保障，這方面如果採用的是IKE來進行自動的密鑰交換和協商同樣可以做到，因為IKE本身就具有一整套自我保護機制，可以在不安全的網路上安全地認證身份，分發密鑰。具體體現在以下幾種安全保護方面。

當使用IKE在對等體間進行信息交換時，首先要識別對方的合法性，也就是身份認證問題。在IKE中可用於確定對等體身份（對等體的IP地址或名稱）的機制比較全面，包括預共享密鑰PSK （pre-shared key）認證，RSA數字證書（rsa-signature,或稱RSA數字簽名）認證和RSA數字信封認證。

在數字信封中，發送方採用對稱密鑰（需要發送方事先隨機產生一個對稱密鑰）來對要發送的報文進行數字簽名，然後將此對稱密鑰用接收方的公鑰來加密 （這部分稱數字信封）之後，再將加密後的對稱密鑰連同經過數字簽名的報文一起發送給接收方。接收方在收到後，首先用自己的私鑰打開數字信封，即可得到發送方的對稱密鑰，然後再用該對稱密鑰解密原來被數字簽名的報文，驗證發送方的數字簽名是否正確。如果正確，則認證通過；否則認證失敗。

對於預共享密鑰認證方法，當有一個對等體對應多個對等體時，需要為每個對等體配置預共享的密鑰，工作量大，所以該方法在小型網路中容易建立，但安全性較低。使用數字證書安全性高，但需要CA來頒發數字證書，適合在大型網路中使用。而數字信封認證用於設備需要符合國家密碼管理局要求時使用（需要使用國家 密碼管理局要求的哈希演算法SM3），且此認證方法只能在IKEv1的主模式協商過程中支持。

以上所提到的用於身份認證的各種密鑰都屬於IKE認證密鑰，支持的演算法有： MD5，SHA1， SHA2-256，SHA2-384，SHA2-512，SM3。MD5演算法使用128位的密鑰，SHA-1演算法使用160位的密鑰，SHA2-256，SHA2-384，SHA2-512分別採用256 位，384位和512位密鑰，SM3使用128位密鑰。它們之間的安全性由高到低順序 是：SM3>SHA2-512>SHA2-384>SHA2-256>SHA1>MD5。 對於普通的安全要求，認證演算法推薦使用SHA2-256，SHA2-384和SHA2-512,不推薦使用MD5和SHA1,對於安全性要求特別高的地方，可採用SM3演算法。

以上所涉及的身份認證密鑰（包括預共享密鑰，公/私鑰），證書都是作為發送方的「驗證數據」要通過對應方式發給對方予以驗證的。

IPSec的數據加密機制主要用在兩個方面：一是在IKE協商階段，保護所傳輸的用於身份認證的數據信息（如共享密鑰、證書、認證密鑰等），二是在IPSec隧道建立後保護在隧道中傳輸的用戶數據。但這里所說的數據加密機制所採用的對稱密鑰機制，即加密和解密採用相同的密鑰，而不是像前面介紹的數字證書身份認證和數字簽名應用中所採用的非對稱密鑰體系。

IKE支持的加密演算法包括:DES，3DES，AES-128，AES-192，AES-256，SM1和SM4等。DES演算法使用56位密鑰，3DES使用168位密鑰，AES-128，AES-192，AES-256分別使用128，192和256位密鑰，SM1和SM4均使用128位密鑰。這些加密演算法的安全級別由高到低的順序是：SM4 > SMI1> AES-256 > AES-192 > AES-128 > 3DES > DES,推薦使用AES-256、AES-192和AES-128,不推薦使用3DES和DES演算法， SM1和SM4僅建議在保密及安全性要求非常高的地方採用，因為它們的運算速度比較慢。非對稱密鑰體系中通常使用的是RSA或DSA （Digital Signature Algorithm,數字簽名演算法）加密演算法。

Diffie-HeLlman演算法是一種公開密鑰演算法。通信雙方可在不傳送密鑰的情況下，僅通過交換一些數據，即可計算出雙方共享的密鑰。而且可以做到，即使第三方截獲了雙方用於計算密鑰的所有交換數據，也不足以計算出真正的密鑰。

DH主要用於IKE動態協商時重新生成新的IPSec SA所用的密鑰，因為它可以通 過一系列數據的交換，最終計算出雙方共享的密鑰，而不依賴於在前期生成的密鑰生成材料。但DH沒有提供雙方身份的任何信息，不能確定交換的數據是否發送給合法方，第三方可以通過截獲的數據與通信雙方都協商密鑰，共享通信，從而獲取和傳遞信息，所以IKE還需要身份認證來對對等體身份進行認證。

PFS (Perfect Forward Secrecy,完善的前向安全性)是一種安全特性，指一個密鑰被破解後並不影響其他密鑰的安全性，因為這些密鑰間沒有派生關系。

由本章後面的介紹就可知道，IPSec SA的密鑰是從IKE SA的密鑰導出的。由於一個IKE SA協商可生成一對或多對有一定派生關系的IPSec SA，所以當IKE的密鑰被竊取後，攻擊者很可能通過收集到足夠的信息來非法導出IPSec SA的密鑰，這樣就不安全了。如果在生成IPSec階段啟用了PFS，即可通過執行一次額外的DH交換，生成新的，獨立的IPSec SA，這樣就可以保證IPSec SA密鑰的安全了。

上文已提到，IKEvl版本產生最終的IPSecSA是需要經過兩個階段，分別用來建立IKESA和IPSecSA。本節先介紹第一階段。
IKEvl的第一階段的最終目的是在對等體之間創建了一條安全通道，建立對等 體的IKESA。在這個階段中，IKE對等體間彼此驗證對方，並確定共同的會話密 鑰。這個階段需要用到Diffie-Hellman （簡稱DH）演算法進行密鑰交換，完成IKE SA 建立，使後面的第二階段過程的協商過程受到安全保護。
在IKEvl版本中，建立IKE SA的過程有主模式（Main Mode）和野蠻模式（Aggr essive Mode,也稱「積極模式」）兩種交換模式。下面分別予以介紹。

在IKEv1的主模式的IKE SA建立過程中，包含三次雙向消息交換，用到了六條信息，交換過程如圖所示。

這6條消息其實總體上是三個步驟，各包含兩條相鄰編號的消息。

第一個步驟對應的是消息①和②，是隧道兩端對等體間通過交換彼此配置的IKE策略協商好要共同採用的IKE安全策略，因為只有雙方都採用相同的安全策略才能相互識別對方加密的數據，並對對方身份進行正確認證。

第二個步驟對應的是消息③和④，是對等體間通過DH演算法交換彼此的密鑰生成所需的參數信息（DH公開值和隨機數nonce等），建立兩端相同的一系列共享密鑰，主要包括用於在第二階段協商的身份認證密鑰和協商數據的加密密鑰。

第三步對應的是消息⑤和⑥，用前面已創建好的加密密鑰彼此相互發送各自的身份（如對等體的IP地址或名稱）和驗證數據（所採用的身份認證方式中的密鑰， 或證書數據等），採用相應認證方法在對等體間進行身份認證。最終完成IKE SA的建立。

在正式進行消息交換前，發起方和接收方必須先計算出各自的cookie （在ISKMP報頭中，可以防重放和DoS攻擊），這些cookie用於標識每個單獨的協商交換消息。RFC建議將源/目IP地址，源/目埠號，本地生成的隨機數，日期和時間進行散列操作生成cookie。cookie成為在IKE協商中交換信息的唯一標識，在IKEv1版本中為Cookie, 在IKEv2版本中的Cookie即為IKE的SPI （安全參數索引）。

下面再具體介紹以上所提到的這6條消息。

如圖所示,野蠻模式只用到三條信息,消息①和②用於在對等體間協商IKE安全策略，交換DH公鑰，必需的輔助信息和身份信息(通常不以IP地址進行標識,而是以主機名進行標識的)。

由野蠻模式和主模式的對比可以發現,與主模式相比，野蠻模式減少了交換信息的數目，提高了協商的速度，但是沒有對身份信息和驗證數據進行加密保護，因為雙方在發送身份信息時(對應第①和第②條消息)是不加密的(但主模式中發送的身份信息和驗證數據是加密的，對應第⑤和第⑥條消息)。雖然野蠻模式不提供身份保護，它仍可以滿足某些特定的網路環境需求。

當IPSec 隧道中存在NAT設備時，需要啟用NAT穿越功能，而NAT轉換會改變對等體的IP地址，由於野蠻模式不依賴於IP地址標識身份，使得如果採用預共享密鑰驗證方法時，NAT穿越只能在野蠻模式中實現。如果發起方的P地址不固定或者無法預知，而雙方都希望採用預共享密鑰驗證方法來創建IKE SA，則只能採用野蠻模式。

如果發起方已知響應方的策略，或者對響應者的策略有全面的了解，採用野蠻模式能夠更快地創建IKE SA.

ikev1版本的第二階段就是要在第一階段基礎上最終建立一對SA ,它只有一種模式,即快速模式(Quick Mode )。快速模式的協商是受SA 保護的,整個協商過程如圖所示。

在快速模式的協商過程中主要是完成以下IPSec 安全策略的確定:

在上述幾方面達成一致後,將建立起兩個PSec SA ,分別用於入站和出站通信。
在消息①和②中的IPSec安全提議包括了安全協議，spi，IPSec封裝模式，PfS(可選)，IPSec SA生存周期等。這兩條消息中還包括雙方的身份信息(如IP地址，傳輸層埠)，驗證數據(包括所採用的身份認證機制中的密鑰，證書等)，以及nonce (一個隨機數，用於抗重放，還被用作密碼生成的材料，僅當啟用PFS時用到)。接收方會利用所收到的對方數據生成加密密鑰,消息③為確認消息,通過確認發送方收到該階段的消息②,使響應方獲知可以正式通信了。

IKEv1需要經歷兩個階段,至少交換6條消息才能最終建立一對PSec SA, 而IKEv2在保證安全性的前提下, 減少了傳遞的信息和交換的次數,實現起來更簡單。

IKEv2保留了IKEv1的大部分特性,而且IKEv1的一部分擴展特性(如NAT穿越)作為IKEv2協議的組成部分被引入到IKEv2框架中。與IKEV1不同,IKEv2中所有消息都以「請求-響應」的形式成對出現，響應方都要對發起方發送的消息進行確認,如果在規定的時間內沒有收到確認報文,發起方需要對報文進行重傳處理,提高了安全性。

IKEv2還可以防禦DoS攻擊。在IKEv1中,當網路中的攻擊方一直重放消息,響應方需要通過計算後,對其進行響應而消耗設備資源,造成對響應方的DoS攻擊。而在KEv2中,響應方收到請求後,並不急於計算,而是先向發起方發送一個cookie類型的Notify載荷(即一個特定的數值),兩者之後的通信必須保持Fcookie與發起方之間的對應關系,有效防禦了DoS攻擊。

IKEv2定義了三種交換類型:初始交換(InitialExchanges)，創建子SA交換(Create _Child _SA Exchange)以及通知交換(InformationalExchange)。IKEv2通過初始交換就可以完成一個IKE SA和第一對IPSec SA的協商建立。如果要求建立的IPSec SA大於一對時, 每一對IPSec SA值只需要額外增加一次創建子SA交換(而如果採用IKEv1,則子SA 的創建仍然需要經歷兩個階段)。

IKEv2初始交換對應IKEv1的第一階段，初始交換包含兩次交換四條消息,如圖所示。消息①和②屬於第一次交換，以明文方式完成IKE SA的參數協商,主要是協商加密演算法，交換nonce 值，完成一次DH交換,從而生成用於加密,並驗證後續交換的密鑰材料。消息③和④屬於第二次交換,以加密方式完成身份認證(通過交換身份信息和驗證數據)，對前兩條信息的認證和IPSec SA的參數協商。

在初始交換完成後,可以由任何一方發起創建子SA交換,該次交換中的發起者和初始交換中的發起者可能是不同的。該交換必須在初始交換完成後進行,交換消息由初始交換協商的密鑰進行保護。

創建子SA交換包含兩條消息,用於一個IKE SA創建多個IPSec SA或IKE的重協商,對應IKEv1的第二階段。如果需要支持PFS,創建子SA交換可額外進行一次DH交換，建立勇於建立IPSEC SA的新密鑰。

通信雙方在密鑰協商期間,某一方可能希望向對方發送控制信息,通知某些錯誤或者某事件的發生,這就需要由「通知交換過程來完成。
通知交換如圖2-15所示,用於對等體間傳遞一些控制信息,如錯誤信息,刪除消息,或通知信息。收到信息消息的一方必須進行響應,響應消息中可能不包含任何載荷。通知交換只能發生在初始交換之後,其控制信息可以是IKE SA的(由IKES A保護該交換),也可以是子SA的(由子SA保護該交換)。