密钥交换算法视频

‘壹’ 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保护该交换)。