很高兴和大家一起分享三大加密算法的知识，希望对各位有所帮助。
SSL (Secure Sockets Layer) 安全套接层，是一种安全协议，经历了 SSL 1.0、2.0、3.0 版本后发展成了标准安全协议 - TLS (Transport Layer Security) 传输层安全性协议。TLS 有 1.0 (RFC 2246)、1.1(RFC 4346)、1.2(RFC 5246)、1.3(RFC 8446) 版本。
TLS 在实现上分为 记录层 和 握手层 两层，其中握手层又含四个子协议: 握手协议 (handshake protocol)、更改加密规范协议 (change cipher spec protocol)、应用数据协议 (application data protocol) 和警告协议 (alert protocol)
只需配置浏览器和服务器相关设置开启 TLS，即可实现 HTTPS，TLS 高度解耦，可装可卸，与上层高级应用层协议相互协作又相互独立。
TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。
TLS 的基本工作方式是，客户端使用非对称加密与服务器进行通信，实现身份验证并协商对称加密使用的密钥，然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信，不同的节点之间采用的对称密钥不同，从而可以保证信息只能通信双方获取。
例如，在 HTTPS 协议中，客户端发出请求，服务端会将公钥发给客户端，客户端验证过后生成一个密钥再用公钥加密后发送给服务端（非对称加密），双方会在 TLS 握手过程中生成一个协商密钥（对称密钥），成功后建立加密连接。通信过程中客户端将请求数据用协商密钥加密后发送，服务端也用协商密钥解密，响应也用相同的协商密钥。后续的通信使用对称加密是因为对称加解密快，而握手过程中非对称加密可以保证加密的有效性，但是过程复杂，计算量相对来说也大。
记录协议负责在传输连接上交换的所有底层消息，并且可以配置加密。每一条 TLS 记录以一个短标头开始。标头包含记录内容的类型 (或子协议)、协议版本和长度。原始消息经过分段 (或者合并)、压缩、添加认证码、加密转为 TLS 记录的数据部分。
记录层将信息块分割成携带 2^14 字节 (16KB) 或更小块的数据的 TLSPlaintext 记录。
记录协议传输由其他协议层提交给它的不透明数据缓冲区。如果缓冲区超过记录的长度限制（2^14），记录协议会将其切分成更小的片段。反过来也是可能的，属于同一个子协议的小缓冲区也可以组合成一个单独的记录。
压缩算法将 TLSPlaintext 结构转换为 TLSCompressed 结构。如果定义 CompressionMethod 为 null 表示不压缩
流加密（BulkCipherAlgorithm）将 TLSCompressed.fragment 结构转换为流 TLSCiphertext.fragment 结构
MAC 产生方法如下：
seq_num（记录的序列号）、hash（SecurityParameters.mac_algorithm 指定的哈希算法）
块加密（如 RC2 或 DES），将 TLSCompressed.fragment 结构转换为块 TLSCiphertext.fragment 结构
padding: 添加的填充将明文长度强制为块密码块长度的整数倍。填充可以是长达 255 字节的任何长度，只要满足 TLSCiphertext.length 是块长度的整数倍。长度大于需要的值可以阻止基于分析交换信息长度的协议攻击。填充数据向量中的每个 uint8 必须填入填充长度值 (即 padding_length)。
padding_length: 填充长度应该使得 GenericBlockCipher 结构的总大小是加密块长度的倍数。合法值范围从零到 255（含）。 该长度指定 padding_length 字段本身除外的填充字段的长度
加密块的数据长度（TLSCiphertext.length）是 TLSCompressed.length，CipherSpec.hash_size 和 padding_length 的总和加一
加密和 MAC 功能将 TLSCompressed 结构转换为 TLSCiphertext。记录的 MAC 还包括序列号，以便可以检测到丢失，额外或重复的消息。
记录协议需要一种算法，从握手协议提供的安全性参数生成密钥、 IV 和 MAC secret.
主密钥 (Master secret): 在连接中双方共享的一个 48 字节的密钥
客户随机数 (client random): 由客户端提供的 32 字节值
服务器随机数 (server random): 由服务器提供的 32 字节值
握手是 TLS 协议中最精密复杂的部分。在这个过程中，通信双方协商连接参数，并且完成身 份验证。根据使用的功能的不同，整个过程通常需要交换 6~10 条消息。根据配置和支持的协议扩展的不同，交换过程可能有许多变种。在使用中经常可以观察到以下三种流程：(1) 完整的握手， 对服务器进行身份验证；(2) 恢复之前的会话采用的简短握手；(3) 对客户端和服务器都进行身份验证的握手。
握手协议消息的标头信息包含消息类型（1 字节）和长度（3 字节），余下的信息则取决于消息类型：
每一个 TLS 连接都会以握手开始。如果客户端此前并未与服务器建立会话，那么双方会执行一次完整的握手流程来协商 TLS 会话。握手过程中，客户端和服务器将进行以下四个主要步骤:
下面介绍最常见的握手规则，一种不需要验证客户端身份但需要验证服务器身份的握手:
这条消息将客户端的功能和首选项传送给服务器。
是将服务器选择的连接参数传回客户端。
这个消息的结构与 ClientHello 类似，只是每个字段只包含一个选项，其中包含服务端的 random_S 参数 (用于后续的密钥协商)。服务器无需支持客户端支持的最佳版本。如果服务器不支持与客户端相同的版本，可以提供某个其他版本以期待客户端能够接受
图中的 Cipher Suite 是后续密钥协商和身份验证要用的加密套件，此处选择的密钥交换与签名算法是 ECDHE_RSA，对称加密算法是 aes-GCM，后面会讲到这个
还有一点默认情况下 TLS 压缩都是关闭的，因为 CRIME 攻击会利用 TLS 压缩恢复加密认证 cookie，实现会话劫持，而且一般配置 gzip 等内容压缩后再压缩 TLS 分片效益不大又额外占用资源，所以一般都关闭 TLS 压缩
典型的 Certificate 消息用于携带服务器 X.509 证书链 。
服务器必须保证它发送的证书与选择的算法套件一致。比方说，公钥算法与套件中使用的必须匹配。除此以外，一些密钥交换算法依赖嵌入证书的特定数据，而且要求证书必须以客户端支持的算法签名。所有这些都表明服务器需要配置多个证书（每个证书可能会配备不同的证书链）。
Certificate 消息是可选的，因为并非所有套件都使用身份验证，也并非所有身份验证方法都需要证书。更进一步说，虽然消息默认使用 X.509 证书，但是也可以携带其他形式的标志；一些套件就依赖 PGP 密钥
携带密钥交换需要的额外数据。ServerKeyExchange 是可选的，消息内容对于不同的协商算法套件会存在差异。部分场景下，比如使用 RSA 算法时，服务器不需要发送此消息。
ServerKeyExchange 仅在服务器证书消息（也就是上述 Certificate 消息）不包含足够的数据以允许客户端交换预主密钥（premaster secret）时才由服务器发送。
比如基于 DH 算法的握手过程中，需要单独发送一条 ServerKeyExchange 消息带上 DH 参数:
表明服务器已经将所有预计的握手消息发送完毕。在此之后，服务器会等待客户端发送消息。
客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证内容包括如下:
由 PKI 体系 的内容可知，对端发来的证书签名是 CA 私钥加密的，接收到证书后，先读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性；然后去查询证书的吊销情况等
合法性验证通过之后，客户端计算产生随机数字的预主密钥（Pre-master），并用证书公钥加密，发送给服务器并携带客户端为密钥交换提供的所有信息。这个消息受协商的密码套件的影响，内容随着不同的协商密码套件而不同。
此时客户端已经获取全部的计算协商密钥需要的信息: 两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，然后得到协商密钥(用于之后的消息加密)
图中使用的是 ECDHE 算法，ClientKeyExchange 传递的是 DH 算法的客户端参数，如果使用的是 RSA 算法则此处应该传递加密的预主密钥
通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信
Finished 消息意味着握手已经完成。消息内容将加密，以便双方可以安全地交换验证整个握手完整性所需的数据。
这个消息包含 verify_data 字段，它的值是握手过程中所有消息的散列值。这些消息在连接两端都按照各自所见的顺序排列，并以协商得到的主密钥 (enc_key) 计算散列。这个过程是通过一个伪随机函数（pseudorandom function，PRF）来完成的，这个函数可以生成任意数量的伪随机数据。
两端的计算方法一致，但会使用不同的标签（finished_label）：客户端使用 client finished，而服务器则使用 server finished。
因为 Finished 消息是加密的，并且它们的完整性由协商 MAC 算法保证，所以主动网络攻击者不能改变握手消息并对 vertify_data 的值造假。在 TLS 1.2 版本中，Finished 消息的长度默认是 12 字节（96 位），并且允许密码套件使用更长的长度。在此之前的版本，除了 SSL 3 使用 36 字节的定长消息，其他版本都使用 12 字节的定长消息。
服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，同样计算得到协商密钥: enc_key = PRF(Pre_master, "master secret", random_C + random_S) ;
同样计算之前所有收发信息的 hash 值，然后用协商密钥解密客户端发送的 verify_data_C，验证消息正确性;
服务端验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信（图中多了一步 New Session Ticket，此为会话票证，会在会话恢复中解释）;
服务器也结合所有当前的通信参数信息生成一段数据 (verify_data_S) 并采用协商密钥 session secret (enc_key) 与算法加密并发送到客户端;
客户端计算所有接收信息的 hash 值，并采用协商密钥解密 verify_data_S，验证服务器发送的数据和密钥，验证通过则握手完成;
开始使用协商密钥与算法进行加密通信。
HTTPS 通过 TLS 层和证书机制提供了内容加密、身份认证和数据完整性三大功能。加密过程中，需要用到非对称密钥交换和对称内容加密两大算法。
对称内容加密强度非常高，加解密速度也很快，只是无法安全地生成和保管密钥。在 TLS 协议中，最后的应用数据都是经过对称加密后传输的，传输中所使用的对称协商密钥(上文中的 enc_key)，则是在握手阶段通过非对称密钥交换而来。常见的 aes-GCM、ChaCha20-Poly1305，都是对称加密算法。
非对称密钥交换能在不安全的数据通道中，产生只有通信双方才知道的对称加密密钥。目前最常用的密钥交换算法有 RSA 和 ECDHE。
RSA 历史悠久，支持度好，但不支持 完美前向安全 - PFS(Perfect Forward Secrecy) ；而 ECDHE 是使用了 ECC（椭圆曲线）的 DH（Diffie-Hellman）算法，计算速度快，且支持 PFS。
在 PKI 体系 一节中说明了仅有非对称密钥交换还是无法抵御 MITM 攻击的，所以需要引入了 PKI 体系的证书来进行身份验证，其中服务端非对称加密产生的公钥会放在证书中传给客户端。
在 RSA 密钥交换中，浏览器使用证书提供的 RSA 公钥加密相关信息，如果服务端能解密，意味着服务端拥有与公钥对应的私钥，同时也能算出对称加密所需密钥。密钥交换和服务端认证合并在一起。
在 ECDH 密钥交换中，服务端使用私钥 (RSA 或 ECDSA) 对相关信息进行签名，如果浏览器能用证书公钥验证签名，就说明服务端确实拥有对应私钥，从而完成了服务端认证。密钥交换则是各自发送 DH 参数完成的，密钥交换和服务端认证是完全分开的。
可用于 ECDHE 数字签名的算法主要有 RSA 和 ECDSA - 椭圆曲线数字签名算法 ，也就是目前密钥交换 + 签名有三种主流选择:
比如我的网站使用的加密套件是 ECDHE_RSA，可以看到数字签名算法是 sha256 哈希加 RSA 加密，在 PKI 体系 一节中讲了签名是服务器信息摘要的哈希值加密生成的
内置 ECDSA 公钥的证书一般被称之为 ECC 证书，内置 RSA 公钥的证书就是 RSA 证书。因为 256 位 ECC Key 在安全性上等同于 3072 位 RSA Key，所以 ECC 证书体积比 RSA 证书小，而且 ECC 运算速度更快，ECDHE 密钥交换 + ECDSA 数字签名是目前最好的加密套件
以上内容来自本文: 开始使用 ECC 证书
关于 ECC 证书的更多细节可见文档: ECC Cipher Suites for TLS - RFC4492
使用 RSA 进行密钥交换的握手过程与前面说明的基本一致，只是没有 ServerKeyExchange 消息，其中协商密钥涉及到三个参数 (客户端随机数 random_C、服务端随机数 random_S、预主密钥 Premaster secret)，
其中前两个随机数和协商使用的算法是明文的很容易获取，最后一个 Premaster secret 会用服务器提供的公钥加密后传输给服务器 (密钥交换)，如果这个预主密钥被截取并破解则协商密钥也可以被破解。
RSA 算法的细节见: wiki 和 RSA算法原理（二）- 阮一峰
RSA 的算法核心思想是利用了极大整数 因数分解 的计算复杂性
而使用 DH(Diffie-Hellman) 算法 进行密钥交换，双方只要交换各自的 DH 参数(在 ServerKeyExchange 发送 Server params，在 ClientKeyExchange 发送 Client params)，不需要传递 Premaster secret，就可以各自算出这个预主密钥
DH 的握手过程如下，大致过程与 RSA 类似，图中只表达如何生成预主密钥:
服务器通过私钥将客户端随机数 random_C，服务端随机数 random_S，服务端 DH 参数 Server params 签名生成 signature，然后在 ServerKeyExchange 消息中发送服务端 DH 参数和该签名；
客户端收到后用服务器给的公钥解密验证签名，并在 ClientKeyExchange 消息中发送客户端 DH 参数 Client params；
服务端收到后，双方都有这两个参数，再各自使用这两个参数生成预主密钥 Premaster secret，之后的协商密钥等步骤与 RSA 基本一致。
关于 DH 算法如何生成预主密钥，推荐看下 Wiki 和 Ephemeral Diffie-Hellman handshake
其核心思想是利用了 离散对数问题 的计算复杂性
算法过程可以抽象成下图:
双方预先商定好了一对 P g 值 (公开的)，而 Alice 有一个私密数 a(非公开，对应一个私钥)，Bob 有一个私密数 b(非公开，对应一个私钥)
对于 Alice 和 Bob 来说通过对方发过来的公钥参数和自己手中的私钥可以得到最终相同的密钥
而第三方最多知道 P g A B，想得到私钥和最后的密钥很困难，当然前提是 a b P 足够大 (RFC3526 文档中有几个常用的大素数可供使用)，否则暴力破解也有可能试出答案，至于 g 一般取个较小值就可以
如下几张图是实际 DH 握手发送的内容:
可以看到双方发给对方的参数中携带了一个公钥值，对应上述的 A 和 B
而且实际用的加密套件是 椭圆曲线 DH 密钥交换 (ECDH) ，利用由椭圆曲线加密建立公钥与私钥对可以更进一步加强 DH 的安全性，因为目前解决椭圆曲线离散对数问题要比因式分解困难的多，而且 ECC 使用的密钥长度比 RSA 密钥短得多(目前 RSA 密钥需要 2048 位以上才能保证安全，而 ECC 密钥 256 位就足够)
关于 椭圆曲线密码学 - ECC ，推荐看下 A Primer on Elliptic Curve Cryptography - 原文 - 译文
尽管可以选择对任意一端进行身份验证，但人们几乎都启用了对服务器的身份验证。如果服务器选择的套件不是匿名的，那么就需要在 Certificate 消息中跟上自己的证书。
相比之下，服务器通过发送 CertificateRequest 消息请求对客户端进行身份验证。消息中列出所有可接受的客户端证书。作为响应，客户端发送自己的 Certificate 消息（使用与服务器发送证书相同的格式），并附上证书。此后，客户端发送 CertificateVerify 消息，证明自己拥有对应的私钥。
只有已经过身份验证的服务器才被允许请求客户端身份验证。基于这个原因，这个选项也被称为相互身份验证（mutual authentication）。
在 ServerHello 的过程中发出，请求对客户端进行身份验证，并将其接受的证书的公钥和签名算法传送给客户端。
它也可以选择发送一份自己接受的证书颁发机构列表，这些机构都用其可分辨名称来表示:
在 ClientKeyExchange 的过程中发出，证明自己拥有的私钥与之前发送的客户端证书中的公钥匹配。消息中包含一条到这一步为止的所有握手消息的签名：
最初的会话恢复机制是，在一次完整协商的连接断开时，客户端和服务器都会将会话的安全参数保存一段时间。希望使用会话恢复的服务器为会话指定唯一的标识，称为会话 ID(Session ID)。服务器在 ServerHello 消息中将会话 ID 发回客户端。
希望恢复早先会话的客户端将适当的 Session ID 放入 ClientHello 消息，然后提交。服务器如果同意恢复会话，就将相同的 Session ID 放入 ServerHello 消息返回，接着使用之前协商的主密钥生成一套新的密钥，再切换到加密模式，发送 Finished 消息。
客户端收到会话已恢复的消息以后，也进行相同的操作。这样的结果是握手只需要一次网络往返。
Session ID 由服务器端支持，协议中的标准字段，因此基本所有服务器都支持，服务器端保存会话 ID 以及协商的通信信息，占用服务器资源较多。
用来替代服务器会话缓存和恢复的方案是使用会话票证（Session ticket）。使用这种方式，除了所有的状态都保存在客户端（与 HTTP Cookie 的原理类似）之外，其消息流与服务器会话缓存是一样的。
其思想是服务器取出它的所有会话数据（状态）并进行加密 (密钥只有服务器知道)，再以票证的方式发回客户端。在接下来的连接中，客户端恢复会话时在 ClientHello 的扩展字段 session_ticket 中携带加密信息将票证提交回服务器，由服务器检查票证的完整性，解密其内容，再使用其中的信息恢复会话。
这种方法有可能使扩展服务器集群更为简单，因为如果不使用这种方式，就需要在服务集群的各个节点之间同步会话。
Session ticket 需要服务器和客户端都支持，属于一个扩展字段，占用服务器资源很少。
三大类，DES，3DES，aes。强度逐渐提高，aes又分为64位，128位和256位密钥长度。
在采用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位密钥。它们之间的安全性由高到低顺序 是：SM3SHA2-512SHA2-384SHA2-256SHA1MD5。 对于普通的安全要求，认证算法推荐使用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保护该交换)。
先来认识三大加密协议：
1、WEP，WEP是Wired Equivalent Privacy的简称，有线等效保密（WEP）协议是对在两台设备间无线传输的数据进行加密的方式，用以防止非法用户窃听或侵入无线网络。WEP是1999年通过的IEEE 802.11b标准的一部分，使用RC4(Rivest Cipher)串流加密技术达到机密性，并使用CRC-32验和达到资料正确性。
2、WPA，WPA全名为Wi-Fi Protected Access，有WPA和WPA2两个标准，是一种保护无线电脑网络(Wi-Fi)安全的系统，它是应研究者在前一代的系统有线等效加密（WEP）中找到的几个严重的弱点而产生的。WPA是源于2004年通过的IEEE802.11i标准，并与之前的11b标准保持兼容。WPA2同样源于IEEE802.11i标准，并于2005年正式得到验证。
通过了解WEP、WAP和WAP2的协议内容，我们不难发现它们是基于不同的标准下产生的。再看看现在的无线网卡市场，也充斥着802.11a/b/g/n四种标准，而它们与加密协议间的兼容性就成了无线网络连接失败的隐患，下面我们通过实例来看看。
无线网卡对加密协议支持程度不同
内置无线网卡可以算作是笔记本的标配，但每款笔记本内置的无线网卡都存在差异。尤其是一些“上了岁数”的笔记本，内置的无线网卡较老，支持的加密协议也很有限。
我们以一款早期的的Intel PRO/Wireless 2100系列无线网卡为例。
Intel PRO/Wireless 2100支持IEEE 802.11b标准和WEP加密协议，但不支持现在主流的WPA和WPA2加密协议。所以如果你用的是此类无线网卡，虽然在无线网络列表中可以搜索到WPA或WPA2加密的无线网络，但却无法连接上这些无线网络，因为你的无线网卡不支持最新的加密协议。
由此可见，想要连接到加密的无线网络，你的无线网卡必须支持相关的无线协议。那么符合IEEE 802.11a/b/g/n标准的无线网卡都支持那些加密协议呢？一起来看看。
标准与协议
通过上表我们可以看到，如果你的笔记本较老，那么内置的无线网卡就会经常受到加密协议的阻挡而无法连接网络。所以在连接无线网络之前，最好先看看你的无线网卡支持何种加密协议。
解决办法：如果急需使用无线网络，可以暂时降低加密协议或不使用任何的加密协议（具体操作见下文）。但最有效的解决办法是换一块全新的内置无线网卡，最好选择支持802.11n标准的，可以做到一劳永逸。
产品的开发快则一个月，慢则一年，那么如何杜绝市面上各种山寨也成为了我们必须要关注的问题，加密芯片可以做到这点，在保障开发者权益的同时也保护了消费者权益，KEROS加密芯片作为该领域的领头者，一直在尽力贡献一份力。特点如下：接口：标准I2C协议接口；算法: 标准aes256 / KAS算法；特殊接口：Random Stream Cipher for Interface；工作温度：工业级 -40℃ ~+85℃；频率：400Khz；存储:2K字节EEPROM（可选）；电压:1.8V~3.6V；封装：SOT23-6，SOP8，TDFN-6。三大加密算法的介绍就聊到这里吧，感谢你花时间阅读本站内容,谢谢。
本文标签：三大加密算法
