目录数据加密对称加密算法分组对称加密应用模式非对称加密常见的非对称算法散列算法常见算法混合加密TLS协议TLS协商协议：TLS记录协议消息认证码数字签名中间人攻击数字证书证书签发国密体系下的证书签发证书信任

数据加密

加密算法主要有三大类：对称加密算法、非对称加密算法、
哈希算法。对称加密算法是指对信息的加密和解密用的是同一
个公共密钥；非对称加密算法是指对信息的加密和解密用的是
不同的密钥；哈希算法是一种压缩映射，可以把任意长度的明
文通过散列算法变换成固定长度的密文。

算法类型	优势	缺点	代表算法
对称加密	计算速度快，加密强度高	提前共享密钥，易泄露	DES、3DES、AES
非对称加密	不需要提前共享密钥	计算效率低，存在中间人攻击可能	RSA、ElGamal、椭圆曲线算法

为什么运算速度不同？在于基础运算的不同
（因为对称加密都是移位、置换等位运算，非对称加密算法以RSA为例，类似于密文=明文^D mod N的幂模运算,其本质是乘法运算，乘法又是用加法器实现的，这里的数字不论D、N都是大数。想想补码加法。。果然还是位运算快捷）

对称加密算法

对称加密算法的优点是加解密的高速度和使用长密钥时的难破解性。不足之处是，交易双方都使用同样钥匙，安全性得不到保证；同时，假设两个用户需要使用对称加密方法加密然后交换数据，则用户最少需要2个密钥并交换使用，如果企业内用户有n个，则整个企业共需要n×(n-1)/2[Cn^2] 个密钥，密钥的生成和分发将是一个大麻烦。

分组对称加密

DES（Data Encryption Standard DES算法的入口参数有三个：Key、Data、Mode。其中Key为8个字节共64位，是DES算法的工作密钥；Data也为8个字节64位，是要被加密或被解密的数据，DES使用的密钥表面上是64位的，然而只有其中的56位被实际用于算法，其余8位可以被用于奇偶校验（第8、16、24、32、40、48、56、64位是校验位，使得每个密钥都有奇数个1），并在算法中被丢弃。因此，DES的有效密钥长度为56位，通常称DES的密钥长度为56位；Mode为DES的工作方式,有两种：加密或解密。

1. 初始置换
其功能是把输入的64位数据块按位重新组合，并把输出分为L0、R0两部分，每部分各长32位，其置换规则为将输入的第58位换到第一位,
第50位换到第2位……依此类推,最后一位是原来的第7位。
L0、R0则是换位输出后的两部分，L0是输出的左32位，R0是右32位,例:设置换前的输入值为D1D2D3……D64,
则经过初始置换后的结果为:L0=D58D50……D8;R0=D57D49……D7。

置换规则表：
L0：
58,50,42,34,26,18,10,2,
60,52,44,36,28,20,12,4,
62,54,46,38,30,22,14,6,
64,56,48,40,32,24,16,8,
R0：
57,49,41,33,25,17,9,1,
59,51,43,35,27,19,11,3,
61,53,45,37,29,21,13,5,
63,55,47,39,31,23,15,7,

2. 逆置换
经过16次迭代运算后,得到L16、R16,将此作为输入，进行逆置换，逆置换正好是初始置换的逆运算，由此即得到密文输出。
此算法是对称加密算法体系中的代表,在计算机网络系统中广泛使用。

3DES：56*3=168，秘钥长度为168位，该方法使用两个密钥，执行三次DES算法，加密的过程是加密-解密-加密，解密的过程是解密-加密-解密。
AES（Advanced Encryption Standard）：，DES使用的56位密钥长度太短，当DES被破解以后，没过多久推出了AES算法，取代 DES 成为对称加密实现的标准。提供了三种长度供选择，128 位、192 位和 256，为了保证性能不受太大的影响，选择128即可；
SM1：128位对称加密。算法安全保密强度及相关软硬件实现性能与 AES 相当，该算法不公开，仅以IP核的形式存在于芯片中。采用该算法已经研制了系列芯片、智能 IC 卡、智能密码钥匙、加密卡、加密机，调用该算法时，需要通过加密芯片的SKF接口进行调用。
SM4算法：SM4分组密码算法是我国自主设计的分组对称密码算法，用于实现数据的加密/解密运算，以保证数据和信息的机密性。要保证一个对称密码算法的安全性的基本条件是其具备足够的密钥长度，SM4算法与AES算法具有相同的密钥长度分组长度128比特，因此在安全性上高于3DES算法。

分组加密每次只能处理固定长度的明文，因此对于过长的内容需要采用一定模式进行分割，《实用密码学》一书中推荐使用密文分组链（Cipher Block Chain，CBC）等模式。

应用模式

CBC：密码分组链接模式，明文被加密前要与前面的密文进行异或运算后再加密，因此只要选择不同的初始向量，相同的密文加密后会形成不同的密文，这是目前应用最广泛的模式。
ECB：最基本的加密模式，也就是通常理解的加密，相同的明文将永远加密成相同的密文，无初始向量，容易受到密码本重放攻击，一般情况下很少用。

非对称加密

非对称密码体制的特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。

对称密码体制中只有一种密钥，并且是非公开的，如果要解密就得让对方知道密钥。所以保证其安全性就是保证密钥的安全，而非对称密钥体制有两种密钥，其中一个是公开的，这样就可以不需要像对称密码那样传输对方的密钥了。

所以说，不论密钥对的用途是什么，只要用到公钥就是别人的公钥，要用到私钥就是自己的私钥。当用于加解密时（假设A向B发送信息，AB都有一对公私钥，且都知道双方的公钥），A使用B的公钥加密，B接收消息后使用B的私钥解密，这样就保证了数据机密性；

当用于数字签名时，将A的消息使用A的私钥进行加密后，形成了一个签名，将消息与签名用B的公钥加密后发给B，B接受密文后使用B的私钥解密，得到明文和发送方的数字签名，再对明文进行哈希计算，得到散列值H。同时，利用A的公钥对接收到的数字签名进行解密，得到数字摘要。最后将数字摘要与散列值H进行对比，如果相同则说明这是发送方发来的消息数据且数据未被篡改。解密过程称为数字签名验证。这样既保证数据的机密性，又保证完整性

常见的非对称算法

非对称加密算法的安全性往往基于数学问题，包括大数质因子分解、离散对数、椭圆曲线等经典数学难题。

RSA：经典的公钥算法，基本原理：寻求两个大素数比较简单，而将它们的乘积进行因式分解却极其困难，因此可以将乘积公开作为加密密钥。

缺点：

RSA 加解密效率远低于 AES/DES/Blowfish 等对称算法，所以如无必要，请尽量使用对称算法进行加解密；
RSA 算法的安全性低于 AES，比如 RSA3072，其破解复杂度仅相当于 AES128，其长度有1024/2048/3072，密钥长度常选择 2048，兼顾安全性和计算效率；

优点：既可以数字签名，又可用于加解密。

ElGamal：由 Taher ElGamal 设计，利用了模运算下求离散对数困难的特性，比 RSA 产生密钥更快。被应用在 PGP 等安全工具中。
ECC椭圆曲线算法（Elliptic Curve Cryptography，ECC）：一种建立公开密钥加密的演算法，基于椭圆曲线数学难题，它的主要优势是在某些情况下它比其他的方法使用更小的密钥——比如RSA加密算法——提供相当的或更高等级的安全。缺点是加解密时间长，只可用于数字签名。
SM2：SM2算法是基于椭圆曲线上点群离散对数难题。该算法已公开。包括SM2-1椭圆曲线数字签名算法，SM2-2椭圆曲线密钥交换协议，SM2-3椭圆曲线公钥加密算法，分别用于实现数字签名、密钥协商和数据加密等功能；
由于该算法基于ECC，故其签名速度与秘钥生成速度都快于RSA。ECC 256位（SM2采用的就是ECC 256位的一种）安全强度比RSA 2048位高，但运算速度快于RSA。

散列算法

这里仅仅只说一下在安全方面的应用，它在其他方面应用也有很多，展开来说感觉太多了：

文件校验

检查文件是否被修改过

md5sum test.sh > test.md5 //生成md5文件
md5sum test.sh -c test.md5 // -c：从指定文件中读取MD5校验和，并进行校验；

数字签名

常见算法

Message Digest（MD）系列，MD算法主要包括MD4、MD5两种,MD4输出为 128 位。已证明不够安全。MD5是MD4 的改进版本。它对输入仍以 512 位进行分组，其输出是 128 位。MD5 比 MD4 更加安全，但过程更加复杂，计算速度要慢一点。MD5的强抗碰撞性已经被攻破。也就是说，现在已经能够产生具备相同散列值的两条不同的消息，因此它也不安全了。
Secure Hash Algorithm（SHA）系列,SHA-1输出长度为160位Hash值，现在也不太安全了，为了提高安全性，制定出更安全的 SHA-224、SHA-256、SHA-384，和 SHA-512 算法（统称为 SHA-2 算法）。

这里提一嘴，MD5、SHA-1国际通用算法已被王小云教授的团队破解，而且参与设计了SM3，太牛了。。

SM3，SM3主要用于数字签名及验证、消息认证码生成及验证、随机数生成等，其算法公开，其安全性及效率与SHA-256相当。

混合加密

而混合加密机制同时结合了对称加密和非对称加密的优点，该机制的主要过程为：先用非对称加密（加解密速度慢）协商出一个临时的对称加密密钥（或称会话密钥），然后双方再通过对称加密算法（计算效率高）对所传递的大量数据进行快速的加密处理，为了保证数据完整性，在加密前要经过HMAC的处理（看情况，如果是自己造协议也可以不用）。

TLS协议

https就是这一机制的典型应用，与以明文方式传输数据的 HTTP 协议不同，HTTPS 在传统的 HTTP 层和 TCP 层之间引入 Transport Layer Security/Secure Socket Layer（TLS/SSL）加密层来实现安全传输。

上图已经有一些解释了，就这个图作一下说明：

数字签名由数字证书的明文内容组成然后通过CA机构私钥进行加密后的密文（下图是证书内容，只有CA机构的公钥可以打开）。

为了防止公钥在网络之中传输容易泄露的问题，浏览器或者操作系统在安装时默认就会植入一些世界公认的可信任CA机构的证书（可以理解里面包含公钥）或者是用户自主导入的根证书
比较关键的是数字签名验证阶段，再拿到服务器给到的数字证书后，用内置的CA证书的公钥去解密数字签名，解密后拿到证书的明文内容，然后和服务器发送的数字证书的明文内容做比较（数字签名=证书上的明文内容被私有加密后），如果发现不匹配，那证明证书可能被篡改过，则就会拒绝链接。

一、客户端发起一个https请求
  1.客户端支持的加密方式
  2.客户端生成的随机数（第一个随机数）
二、服务端收到请求后，拿到随机数，返回
  1.证书（颁发机构（CA）、证书内容本身的数字签名（使用第三方机构的私钥加密）、证书持有者的公钥、证书签名用到的hash算法）
  2.生成一个随机数，返回给客户端（第二个随机数）
三、客户端拿到证书以后做验证
  1.根据颁发机构找到本地的根证书
  2.根据CA得到根证书的公钥，通过公钥对数字签名解密，得到证书的内容摘要 A
  3.用证书提供的算法对证书内容进行摘要，得到摘要 B
  4.通过A和B的对比，也就是验证数字签名
四、验证通过以后，生成一个随机数（第三个随机数），通过证书内的公钥对这个随机数加密，发送给服务器端（随机数1+2+3）通过对称加密得到一个密钥。（会话密钥）
五、通过会话密钥对内容进行对称加密传输

TLS协商协议：

客户端请求（Client hello） 客户端浏览器发送握手信息到服务器，包括
客户端随机数 R1（随机数一方面需要在客户端保存，另一方面需要传送给服务端，客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret ）、支持的加密算法套件（Cipher Suite）类型、协议版本、加密算法等。注意该过程传输为明文。

服务端回应（Server hello） 服务端返回信息，包括服务端随机数 R2（服务器生成的随机数，稍后用于生成”对话密钥”）、选定加密算法套件、协议版本（如果浏览器与服务器支持的版本不一致，服务器关闭加密通信），以及服务器证书。注意该过程为明文。

可选 certificate 浏览器检查带有该网站公钥的证书（下面证书信任涉及到了）。服务器端发送自己的证书清单，因为证书可能是层级结构的，所以处理服务器自己的证书之外，还需要发送为服务器签名的证书。如果是以匿名的方式通信则不需要证书。

可选 ServerKeyExchange

可选 CertificateRequest如果是在需要双向认证，服务器端也需要向客户端索要证书。
如果并不需要客户端认证，则不需要此步骤。

server hello done
服务器端发送server hello done的消息告诉客户端自己的消息结束了。

可选 Certificate对步骤5的回应，客户端发送客户端证书给服务器

ClientKeyExchange 还是分两种情况：

如果是公钥或者RSA模式情况下，客户端将根据客户端生成的随机数和服务器端生成的随机数，生成预备主密码R3，通过该公钥进行加密，返送给服务器端。

PreMaster Secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的
它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成 Master 
Secret。在客户端使用服务端的公钥对PreMaster Secret 
进行加密之后传送给服务端，服务端将使用私钥进行解密得到PreMaster secret。也就是说服务端和客户端都有一份相同的PreMaster secret和随机数。

主密码是根据密码套件中定义的单向散列函数实现的伪随机数生成器+预备主密码+客户端随机数+服务器端随机数生成的。

主密码主要用来生成称密码的密钥，消息认证码的密钥和对称密码的CBC模式所使用的初始化向量。

国密标准下的协商：

更详细的可以看看国密SSL应用标准。

TLS记录协议

TLS记录协议主要负责消息的压缩，加密及数据的认证：

消息首先将会被分段，然后压缩，再计算其消息验证码，然后使用对称密码进行加密，加密使用的是CBC模式，CBC模式的初始向量是通过主密码来生成的。

得到密文之后会附加类型，版本和长度等其他信息，最终组成最后的报文数据。

消息认证码

消息认证码（Hash-based Message Authentication Code，HMAC），利用对称加密，对消息完整性（Integrity）进行保护。

基本过程为对某个消息，利用提前共享的对称密钥和 Hash 算法进行处理，得到 HMAC 值。该 HMAC 值持有方可以向对方证明自己拥有某个对称密钥，并且确保所传输消息内容未被篡改。

典型的 HMAC 生成算法包括 K，H，M 三个参数。K 为提前共享的对称密钥，H 为提前商定的 Hash 算法（如 SHA-256），M 为要传输的消息内容。三个参数缺失了任何一个，都无法得到正确的 HMAC 值。

消息认证码可以用于简单证明身份的场景。如 Alice、Bob 提前共享了 K（对称密钥） 和 H（商定的 Hash 算法）。Alice 需要知晓对方是否为 Bob，可发送一段消息 M 给 Bob。Bob 收到 M 后计算其 HMAC 值并返回给 Alice，Alice 检验收到 HMAC 值的正确性可以验证对方是否真是 Bob。

它的缺点也是对称密钥的缺点，需要提前共享密钥，并且当密钥可能被多方同时拥有（甚至泄露）的场景下，无法追踪消息的真实来源。当采用非对称加密时，即为数字签名。

数字签名

这个图是从网上随便找的，就这个图做一些说明：

一般来说，利用简短的单向散列函数来替代消息明文本身。再进行加密(对消息进行签名)，会快很多；而非对整个消息进行加密，因为是公钥密钥算法，非常耗时。
数字签名是利用了 “没有私钥的人就无法生成使用该私钥所生成的密文” 这一性质来实现的，代表的意义是特定的签名者与特定的消息绑定在一起，生成的密文并非是用于保证机密性，而是用于代表一种只有持有该密钥的人才能生成的信息，明文一旦修改就跟hash摘要不一样了，虽然可以复制签名，但是不能改变他本身的含义，从而保证完整性。
上图数字签名中的消息明文和数字签名没有经过加密，这样没法保证机密性（就是如果把加密比喻衣服，没有加密就相当于光着身子在大街上走来走去，加密后使得传输数据不用赤裸裸的在网络中被所有的“人”看到它
的内容）；只能保证完整性。
如果需要保证机密性，可以考虑加密和数字签名结合起来使用：

当用于数字签名时，将A的消息使用Hash运算后得到一个摘要，使用A的私钥对摘要加密后，形成了一个签名，将消息与签名用B的公钥加密后发给B，

B接受密文后使用B的私钥解密，得到明文和发送方的数字签名，再对明文进行哈希计算，得到散列值H。

同时，利用A的公钥对接收到的数字签名进行解密，得到数字摘要。最后将数字摘要与散列值H进行对比，

如果相同则说明这是发送方发来的消息数据且数据未被篡改。解密过程称为数字签名验证。这样既保证数据的机密性，又保证完整性。

中间人攻击

但是消息认证码、数字签名不能防范中间人攻击（信道不安全），中间人攻击(MITM攻击)：

是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方 直接对话，但事实上整个会话都被攻击者完全控制。在中间人攻 击中，攻击者可以拦截通讯双方的通话并插入新的内容。中间人攻击是一个(缺乏)相互认证的攻击,其根本原因是：数字签名只能验证收到的消息与接收到的数字摘要是否一致，却不能验证发消息的“你”是否是真正的你。

上面非对称加密和数字签名结合后还是有一定的漏洞的，问题在于公钥的分发过程，中间者M可以冒充客户端A的身份（截获A发给B的公钥，并换成中间者M的公钥），这样M可以截获服务端B发送给A的数据，并可以用自己的私钥解密；同样的，中间者M可以冒充服务端B的身份（截获B发给A的公钥，并换成中间者M的公钥），这样M可以截获客户端A发送给B的数据，并可以用自己的私钥解密。这样可以达到篡改数据的目的，偷天换日，通信双方都没有察觉。

数字证书

为了避免上述攻击手段，出现一个专门提供数字签名认证服务的机构——CA（认证中心）。

CA（Certification Authority）：CA的主要功能就是发放、更新、撤销和验证数字签名的认证证书，这一证书即为“数字证书”。
RA（Registration Authority）：对用户身份进行验证，校验数据合法性，负责登记，审核过了就发给 CA；
证书数据库：存放证书，多采用 X.500 系列标准格式。可以配合LDAP 目录服务管理用户信息。

以 X.509 标准为代表的数字证书的核心内容是主体的公钥。加密方式为公钥密码体制，即非对称加密算法——利用一对密钥实施加密和解密：私钥负责解密与签名，公钥负责加密与验签。

证书签发

CA 对用户签发证书实际上是对某个用户公钥，使用 CA 的私钥对其进行签名，证书包含：公钥+申请者与颁发者的相关信息+信息摘要+数字签名）。这样任何人都可以用 CA 的公钥对该证书进行合法性验证。验证成功则认可该证书中所提供的用户公钥内容，实现用户公钥的安全分发。CA就像公安局，数字证书就像身份证，中间者总不能拿着别人身份信息申请我的身份证吧

常见的操作流程有两种：

一、用户自己生成公钥和私钥，然后 CA 来对公钥内容进行签名（用户持有私钥，这种情况下）。

1. 首先，用户B（服务器端）使用非对称加密（RSA或者SM2等）产生一对公私钥，并将公钥及部分个人身份信息（国家、域名、公司、城市等等）传送注册中心RA。
这里证书请求文件(Certificate Signing Request，即 csr 文件)==公钥+个人信息，而私钥信息不会被任何一方知晓。
2. RA审核用户身份并将注册请求发给认证中心CA
3. 认证中心CA在核实用户身份后，对用户的公钥、个人身份信息和认证中心的签名（使用消息摘要算法MD5、SHA-1/2、SM3等结合CA的私钥生成）
等信息加密生成一个数字证书（证书包括使用者的公钥+信息+信息摘要+颁发者的数字签名），并将此证书通过RA发给用户B，这就得到了服务端B的证书，同样的，用户A也可以向CA申请申请A的证书，得到客户端的证书。

国密体系下的证书签发

国内当前是双证书体系，即用户同时拥有签名证书、加密证书两张证书，这个前提下：

用户签名证书的情况同上面签名证书的生成（签名私钥无法导出）。
用户加密证书，则是由KM系统（密钥管理系统）产生并保存。
相应的私钥由用户的签名证书公钥进行加密后传输到客户端。这里有个行业内的术语，叫“密钥不落地”。
国密CA体系里面，加密密钥对是在CA端产生的，和通常的签名证书流程不一样（签名密钥对通常是用户自己产生的，发送证书请求给CA来申请证书）。

国密CA体系里面，加密密钥对是在CA端产生的，和通常的签名证书流程不一样（签名密钥对通常是用户自己产生的，发送证书请求给CA来申请证书）。
那用户怎么安全获得加密证书和私钥呢？国密规范规定，加密私钥需要通过数字信封使用用户的签名公钥加密。CA将加密私钥密文返回给用户，用户因为有对应的签名私钥，因此只有该用户才可以解开密文，获得加密私钥。过程如下：

1. 用户使用U盾产生签名密钥对，生成签名证书请求，发送签名证书请求给CA；
2. CA审核生成签名证书，产生加密密钥对，生成加密证书；
3. CA生成对称密钥，使用用户签名公钥加密，输出对称密钥密文；
4. CA使用对称密钥，加密用户加密私钥，输出加密私钥密文；
5. CA返回给用户签名证书、加密证书、对称密钥密文和加密私钥密文；
6. 用户导入对称密钥密文，使用U盾内部签名私钥解密，获得对称密钥句柄；
7. 用户使用对称密钥句柄解密加密私钥，获得加密私钥明文。
用户使用SKF(U盾)接口时，6）和7）以及导入加密证书时，使用一个API一步完成的，所述过程是在U盾内部的处理。

二、由 CA 直接来生成证书（内含公钥）和对应的私钥发给用户（用户不具备自己产生公私钥的能力，用户和 CA 均持有私钥）。

证书信任

证书中记录了大量信息，其中最重要的包括签发的公开密钥和CA数字签名两个信息。因此，只要使用CA的公钥再次对这个证书进行签名比对，就能证明所记录的公钥是否合法。

先说说证书信任的过程：

1. 当客户端A要访问服务器的时候,服务器端B向客户端A发送受保护的信任证书。
2. 客户端A判断是否对服务端B发送的证书进行信任。
3. 如果信任，则客户端A会安装公钥(服务端B)在客户端,而服务器就拥有受保护证书的私钥,每一次向服务器请求数据的时候,客户端A会将消息明文用公钥加密,服务端B对所传数据通过私钥解密。

根CA信任模式

根信任模式，也称层次信任模式。在该信任模式下，CA中心可以分为多级，用户证书由CA中心签发，各级CA中心之间呈现层次关系。最上级CA中心只有一个，称作根CA，其他CA称作子CA。根CA的数字证书由自己签发，属于自签名证书，子CA
的数字证书由上级CA签发。

在数字签名的时候讲过，验证签名的流程。同样的，子CA验证上一级CA也是相同原理：子CA可以用颁发者的公钥去解密得到颁发者签名，当我们再次用 相同的摘要算法（证书里面有保存所使用的算法）对整个证书做签名，如果得到的签名和证书上的签名是一致的，说明这个证书是可信任的。根据传递性，像一条链条传递上去，这一流程叫做信任链。

交叉信任模式

该信任模式下，根CA之间可以相互签发交叉认证证书，该交叉认证证书等同于子CA证书，网状结构中包含多个CA，提供PKI服务，每个使用者仅信任其证书发放CA发放的证书；这些CA以点对点（peer to peer）模式，也就是互相发给证书方式，达成双向的信任关系。

信任列表模式

该信任模式下，用户可以拥有多个信任锚，信任列表结构是一份被认证机构数字签名后包含“所信认证机构根证书”列表的数据结构。因为使用了数字签名技术，因此信任列表模式具有一定的抗篡改能力。使用者可以通过该数据结构中的一大串认证机构的数字证书遴选出其所信任的认证机构，同时也可以获得其所信任的认证机构的政策依据，windows系统和谷歌浏览器内预置根证书信任列表就是典型的信任列表模式应用。

参考文章：

密码学入门科普（挺有趣的可以看看）

《区块链技术指南》

flydean的博客