算法套件标识
DES (Data Encryption Standard)是分组对称密码算法。
DES算法利用 多次组合替代算法 和 换位算法 ，分散和错乱的相互作用，把明文编制成密码强度很高的密文，它的加密和解密用的是同一算法。
DES算法，是一种 乘积密码 ，其在算法结构上主要采用了 置换 、 代替 、 模二相加 等函数，通过 轮函数 迭代的方式来进行计算和工作。
DES算法也会使用到数据置换技术，主要有初始置换 IP 和逆初始置换 IP^-1 两种类型。DES算法使用置换运算的目的是将原始明文的所有格式及所有数据全部打乱重排。而在轮加密函数中，即将数据全部打乱重排，同时在数据格式方面，将原有的32位数据格式，扩展成为48位数据格式，目的是为了满足S盒组对数据长度和数据格式规范的要求。
一组数据信息经过一系列的非线性变换以后，很难从中推导出其计算的过程和使用的非线性组合；但是如果这组数据信息使用的是线性变换，计算就容易的多。在DES算法中，属于非线性变换的计算过程只有S盒，其余的数据计算和变换都是属于线性变换，所以DES算法安全的关键在于S盒的安全强度。此外，S盒和置换IP相互配合，形成了很强的抗差分攻击和抗线性攻击能力，其中抗差分攻击能力更强一些。
DES算法是一种分组加密机制，将明文分成N个组，然后对各个组进行加密，形成各自的密文，最后把所有的分组密文进行合并，形成最终的密文。
DES加密是对每个分组进行加密，所以输入的参数为分组明文和密钥，明文分组需要置换和迭代，密钥也需要置换和循环移位。在初始置换IP中，根据一张8*8的置换表，将64位的明文打乱、打杂，从而提高加密的强度；再经过16次的迭代运算，在这些迭代运算中，要运用到子密钥；每组形成的初始密文，再次经过初始逆置换 IP^-1 ，它是初始置换的逆运算，最后得到分组的最终密文。
图2右半部分，给出了作用56比特密钥的过程。DES算法的加密密钥是64比特，但是由于密钥的第n*8(n=1,2…8)是校验(保证含有奇数个1)，因此实际参与加密的的密钥只有 56比特 。开始时，密钥经过一个置换，然后经过循环左移和另一个置换分别得到子密钥ki，供每一轮的迭代加密使用。每轮的置换函数都一样，但是由于密钥位的重复迭代使得子密钥互不相同。
DES算法 利用多次组合替代算法和换位算法，分散和错乱的相互作用，把明文编制成密码强度很高的密文，它的加密和解密用的是同一算法。
DES算法详述：DES对64位明文分组(密钥56bit)进行操作。
1、 初始置换函数IP：64位明文分组x经过一个初始置换函数IP，产生64位的输出x0，再将分组x0分成左半部分L0和右半部分R0：即将输入的第58位换到第一位，第50位换到第2位，…，依次类推，最后一位是原来的第7位。L0、R0则是换位输出后的两部分，L0是输出的左32位，R0是右32位。例，设置换前的输入值为D1D2D3…D64，则经过初始置换后的结果为：L0=D58D50…D8；R0=D57D49…D7.其置换规则如表1所示。
DES加密过程最后的逆置换 IP^-1 ，是表1的 逆过程 。就是把原来的每一位都恢复过去，即把第1位的数据，放回到第58位，把第2位的数据，放回到第50位。
2、 获取子密钥 Ki ：DES加密算法的密钥长度为56位，一般表示为64位(每个第8位用于奇偶校验)，将用户提供的64位初始密钥经过一系列的处理得到K1,K2,…,K16，分别作为 1~16 轮运算的 16个子密钥 。
(1). 将64位密钥去掉8个校验位，用密钥置换 PC-1 (表2)置换剩下的56位密钥；
(2). 将56位分成前28位C0和后28位D0，即 PC-1(K56)=C0D0 ;
(3). 根据轮数，这两部分分别循环左移1位或2位，表3：
(4). 移动后，将两部分合并成56位后通过压缩置换PC-2(表4)后得到48位子密钥，即Ki=PC-2(CiDi).
子密钥产生如图2所示：
3、 密码函数F(非线性的)
(1). 函数F的操作步骤：密码函数F 的输入是32比特数据和48比特的子密钥：
A．扩展置换(E):将数据的右半部分Ri从32位扩展为48位。位选择函数(也称E盒)，如表5所示：
B．异或：扩展后的48位输出E(Ri)与压缩后的48位密钥Ki作异或运算；
C．S盒替代：将异或得到的48位结果分成八个6位的块，每一块通过对应的一个S盒产生一个4位的输出。
(2)、D、P盒置换：将八个S盒的输出连在一起生成一个32位的输出，输出结果再通过置换P产生一个32位的输出即：F(Ri,Ki)，F(Ri,Ki)算法描述如图3，最后，将P盒置换的结果与最初的64位分组的左半部分异或，然后，左、右半部分交换，开始下一轮计算。
4、密文输出：经过16次迭代运算后，得到L16、R16，将此作为输入，进行逆置换，即得到密文输出。逆置换正好是初始置的逆运算。例如，第1位经过初始置换后，处于第40位，而通过逆置换，又将第40位换回到第1位，其逆置换规则如表8所示：
图4为DES算法加密原理图：
DES算法加密和解密过程采用相同的算法，并采用相同的加密密钥和解密密钥，两者的区别是：(1)、DES加密是从L0、R0到L15、R15进行变换，而解密时是从L15、R15到L0、R0进行变换的；(2)、加密时各轮的加密密钥为K0K1…K15，而解密时各轮的解密密钥为K15K14…K0；(3)、加密时密钥循环左移，解密时密钥循环右移。
DES加密过程分析：
(1)、首先要生成64位密钥，这64位的密钥经过“子密钥算法”换转后，将得到总共16个子密钥。将这些子密钥标识为Kn(n=1,2,…,16)。这些子密钥主要用于总共十六次的加密迭代过程中的加密工具。
(2)、其次要将明文信息按64位数据格式为一组，对所有明文信息进行分组处理。每一段的64位明文都要经过初试置换IP，置换的目的是将数据信息全部打乱重排。然后将打乱的数据分为左右两块，左边一块共32位为一组，标识为L0；右边一块也是32位为一组，标识为R0.
(3)、置换后的数据块总共要进行总共十六次的加密迭代过程。加密迭代主要由加密函数f来实现。首先使用子密钥K1对右边32位的R0进行加密处理，得到的结果也是32位的；然后再将这个32位的结果数据与左边32位的L0进行模2处理，从而再次得到一个32位的数据组。我们将最终得到的这个32位组数据，作为第二次加密迭代的L1，往后的每一次迭代过程都与上述过程相同。
(4)、在结束了最后一轮加密迭代之后，会产生一个64位的数据信息组，然后我们将这个64位数据信息组按原有的数据排列顺序平均分为左右两等分，然后将左右两等分的部分进行位置调换，即原来左等分的数据整体位移至右侧，而原来右等分的数据则整体位移至左侧，这样经过合并后的数据将再次经过逆初始置换IP^-1的计算，我们最终将得到一组64位的密文。
DES解密过程分析：DES的解密过程与它的加密过程是一样的，这是由于DES算法本身属于对称密码体制算法，其加密和解密的过程可以共用同一个过程和运算。
DES加密函数f：在DES算法中，要将64位的明文顺利加密输出成64位的密文，而完成这项任务的核心部分就是加密函数f。加密函数f的主要作用是在第m次的加密迭代中使用子密钥Km对Km-1进行加密操作。加密函数f在加密过程中总共需要运行16轮。
十六轮迭代算法：它先将经过置换后的明文分成两组，每组32位；同时密钥也被分成了两组，每组28位，两组密钥经过运算，再联合成一个48位的密钥，参与到明文加密的运算当中。S盒子，它由8个4*16的矩阵构成，每一行放着0到15的数据，顺序各个不同，是由IBM公司设计好的。经过异或运算的明文，是一个48位的数据，在送入到S盒子的时候，被分成了8份，每份6位，每一份经过一个S盒子，经过运算后输出为4位，即是一个0到15的数字的二进制表示形式。具体运算过程为，将输入的6位中的第1位为第6位合并成一个二进制数，表示行号，其余4位也合并成一个二进制数，表示列号。在当前S盒子中，以这个行号和列号为准，取出相应的数，并以二进制的形式表示，输出，即得到4位的输出，8个S盒子共计32位。
DES算法优缺点：
(1)、产生密钥简单，但密钥必须高度保密，因而难以做到一次一密；
(2)、DES的安全性依赖于密钥的保密。攻击破解DES算法的一个主要方法是通过密钥搜索，使用运算速度非常高的计算机通过排列组合枚举的方式不断尝试各种可能的密钥，直到破解为止。一般，DES算法使用56位长的密钥，通过简单计算可知所有可能的密钥数量最多是2^56个。随着巨型计算机运算速度的不断提高，DES算法的安全性也将随之下降，然而在一般的民用商业场合，DES的安全性仍是足够可信赖的。
(3)、DES算法加密解密速度比较快，密钥比较短，加密效率很高但通信双方都要保持密钥的秘密性，为了安全还需要经常更换DES密钥。
参考链接 ： https://blog.csdn.net/fengbingchun/article/details/42273257
⑵ 国密算法是什么呢
国密算法是国家密码局制定标准的一系列算法。其中包括了对称加密算法，椭圆曲线非对称加密算法，杂凑算法。具体包括SM1、SM2、SM3、SMS4等，其中：
SM1：对称加密算法，加密强度为128位，采用硬件实现。
SM2：国家密码管理局公布的公钥算法，其加密强度为256位。其它几个重要的商用密码算法包括：
SM3：密码杂凑算法，杂凑值长度为32字节，和SM2算法同期公布，参见《国家密码管理局公告（第 22 号）》。
SMS4：对称加密算法，随WAPI标准一起公布，可使用软件实现，加密强度为128位。
案例
例如：在门禁应用中，采用SM1算法进行身份鉴别和数据加密通讯，实现卡片合法性的验证，保证身份识别的真实性。安全是关系国家、城市信息、行业用户、百姓利益的关键问题。国家密码管理局针对现有重要门禁系统建设和升级改造应用也提出指导意见，加强芯片、卡片、系统的标准化建设。
⑶ 文本、语音相似度算法
前段时间公司项目用到了语音识别,图像识别,视频识别等,其实不能说是识别,应该说是相似度对比吧,毕竟相似度对比还上升不了到识别哈,等以后有了更深的理解再来讨论修改下!这次就当做一个总结吧!
其实它的原理和视频图像相似度算法类似，将一系列的向量,特征,权重,进行合并,然后降维降到一维,其实这个算法也就是采用降维技术,将所有的特征都用一个唯一标识来表示.然后这个标识是经过这个算法内部的计算,再利用海明距离计算相似度，视频和图片是经过汉明距离计算的
文本我们是采用simhash算法：
1.我们给文本里面的词进行分词,我们是用ik算法,这个算法就是while循环,读取一行,然后调用ik智能分词的类,智能去切割里面的分词;
2.根据里面的词频,simhash算法会加一个权重,当然,得词频达到多少个的时候才会有有权重,这也是它的缺点,一般文本数据较少的时候,他是不准确的,一般数据量在500+;算法内部的话会将一系列的向量,特征,权重,进行合并,然后降维降到一维,其实这个算法也就是采用降维技术,将所有的特征都用一个唯一标识来表示.然后这个标识是经过这个算法内部的计算,然后得到的一个指纹签名；
3.然后对比两个文本的相似度就是将两个指纹签名进行海明距离计算,如果海明距离<8(根据业务和场景去判断这个值，8是建议，参考)的话,表示两个相似,小于3的话.表示两个文本重复.
simhash算法我们还可以做语音相似度,它的基本原理就是根据傅里叶变换处理得到声波的形状。
语音的坡度如果向上我们就用1表示,向下我们就用0表示,这样的话,我们也可以用二进制码去描述一首歌曲.得到一个唯一的指纹签名,对比两个音频的相似度就是将两个指纹签名进行海明距离计算<8的话,我们就默认两个音频相似.
总结：都是把特征降到一维，然后采用海明距离计算。计算的值小于多少时，就当做是相似。我这边讲的太浅了，实在领悟有限，时间有限，触摸不深，等下次有新的领悟再来补充！
⑷ OpenSSL 入门：密码学基础知识
本文是使用 OpenSSL 的密码学基础知识的两篇文章中的第一篇，OpenSSL 是在 Linux 和其他系统上流行的生产级库和工具包。（要安装 OpenSSL 的最新版本，请参阅 这里 。）OpenSSL 实用程序可在命令行使用，程序也可以调用 OpenSSL 库中的函数。本文的示例程序使用的是 C 语言，即 OpenSSL 库的源语言。
本系列的两篇文章涵盖了加密哈希、数字签名、加密和解密以及数字证书。你可以从 我的网站 的 ZIP 文件中找到这些代码和命令行示例。
让我们首先回顾一下 OpenSSL 名称中的 SSL。
安全套接字层 (Secure Socket Layer)（SSL）是 Netscape 在 1995 年发布的一种加密协议。该协议层可以位于 HTTP 之上，从而为 HTTPS 提供了 S： 安全(secure)。SSL 协议提供了各种安全服务，其中包括两项在 HTTPS 中至关重要的服务：
SSL 有多个版本（例如 SSLv2 和 SSLv3），并且在 1999 年出现了一个基于 SSLv3 的类似协议 传输层安全性(Transport Layer Security)（TLS）。TLSv1 和 SSLv3 相似，但不足以相互配合工作。不过，通常将 SSL/TLS 称为同一协议。例如，即使正在使用的是 TLS（而非 SSL），OpenSSL 函数也经常在名称中包含 SSL。此外，调用 OpenSSL 命令行实用程序以 openssl 开始。
除了 man 页面之外，OpenSSL 的文档是零零散散的，鉴于 OpenSSL 工具包很大，这些页面很难以查找使用。命令行和代码示例可以将主要主题集中起来。让我们从一个熟悉的示例开始（使用 HTTPS 访问网站），然后使用该示例来选出我们感兴趣的加密部分进行讲述。
此处显示的 client 程序通过 HTTPS 连接到 Google：
可以从命令行编译和执行该程序（请注意 -lssl 和 -lcrypto 中的小写字母 L）：
该程序尝试打开与网站 www.google.com 的安全连接。在与 Google Web 服务器的 TLS 握手过程中，client 程序会收到一个或多个数字证书，该程序会尝试对其进行验证（但在我的系统上失败了）。尽管如此，client 程序仍继续通过安全通道获取 Google 主页。该程序取决于前面提到的安全工件，尽管在上述代码中只着重突出了数字证书。但其它工件仍在幕后发挥作用，稍后将对它们进行详细说明。
通常，打开 HTTP（非安全）通道的 C 或 C++ 的客户端程序将使用诸如文件描述符或网络套接字之类的结构，它们是两个进程（例如，这个 client 程序和 Google Web 服务器）之间连接的端点。另一方面，文件描述符是一个非负整数值，用于在程序中标识该程序打开的任何文件类的结构。这样的程序还将使用一种结构来指定有关 Web 服务器地址的详细信息。
这些相对较低级别的结构不会出现在客户端程序中，因为 OpenSSL 库会将套接字基础设施和地址规范等封装在更高层面的安全结构中。其结果是一个简单的 API。下面首先看一下 client 程序示例中的安全性详细信息。
在与 Web 服务器握手期间，client 程序会接收一个或多个数字证书，以认证服务器的身份。但是，client 程序不会发送自己的证书，这意味着这个身份验证是单向的。（Web 服务器通常配置为 不 需要客户端证书）尽管对 Web 服务器证书的验证失败，但 client 程序仍通过了连接到 Web 服务器的安全通道继续获取 Google 主页。
为什么验证 Google 证书的尝试会失败？典型的 OpenSSL 安装目录为 /etc/ssl/certs，其中包含 ca-certificates.crt 文件。该目录和文件包含着 OpenSSL 自带的数字证书，以此构成 信任库(truststore)。可以根据需要更新信任库，尤其是可以包括新信任的证书，并删除不再受信任的证书。
client 程序从 Google Web 服务器收到了三个证书，但是我的计算机上的 OpenSSL 信任库并不包含完全匹配的证书。如目前所写，client 程序不会通过例如验证 Google 证书上的数字签名（一个用来证明该证书的签名）来解决此问题。如果该签名是受信任的，则包含该签名的证书也应受信任。尽管如此，client 程序仍继续获取页面，然后打印出 Google 的主页。下一节将更详细地介绍这些。
让我们从客户端示例中可见的安全工件（数字证书）开始，然后考虑其他安全工件如何与之相关。数字证书的主要格式标准是 X509，生产级的证书由诸如 Verisign 的 证书颁发机构(Certificate Authority)（CA）颁发。
数字证书中包含各种信息（例如，激活日期和失效日期以及所有者的域名），也包括发行者的身份和数字签名（这是加密过的加密哈希值）。证书还具有未加密的哈希值，用作其标识指纹。
哈希值来自将任意数量的二进制位映射到固定长度的摘要。这些位代表什么（会计报告、小说或数字电影）无关紧要。例如， 消息摘要版本 5(Message Digest version 5)（MD5）哈希算法将任意长度的输入位映射到 128 位哈希值，而 SHA1（ 安全哈希算法版本 1(Secure Hash Algorithm version 1)）算法将输入位映射到 160 位哈希值。不同的输入位会导致不同的（实际上在统计学上是唯一的）哈希值。下一篇文章将会进行更详细的介绍，并着重介绍什么使哈希函数具有加密功能。
数字证书的类型有所不同（例如根证书、中间证书和最终实体证书），并形成了反映这些证书类型的层次结构。顾名思义，根证书位于层次结构的顶部，其下的证书继承了根证书所具有的信任。OpenSSL 库和大多数现代编程语言都具有 X509 数据类型以及处理此类证书的函数。来自 Google 的证书具有 X509 格式，client 程序会检查该证书是否为 X509_V_OK。
X509 证书基于 公共密钥基础结构(public-key infrastructure)（PKI），其中包括的算法（RSA 是占主导地位的算法）用于生成密钥对：公共密钥及其配对的私有密钥。公钥是一种身份： Amazon 的公钥对其进行标识，而我的公钥对我进行标识。私钥应由其所有者负责保密。
成对出现的密钥具有标准用途。可以使用公钥对消息进行加密，然后可以使用同一个密钥对中的私钥对消息进行解密。私钥也可以用于对文档或其他电子工件（例如程序或电子邮件）进行签名，然后可以使用该对密钥中的公钥来验证签名。以下两个示例补充了一些细节。
在第一个示例中，Alice 将她的公钥分发给全世界，包括 Bob。然后，Bob 用 Alice 的公钥加密邮件，然后将加密的邮件发送给 Alice。用 Alice 的公钥加密的邮件将可以用她的私钥解密（假设是她自己的私钥），如下所示：
理论上可以在没有 Alice 的私钥的情况下解密消息，但在实际情况中，如果使用像 RSA 这样的加密密钥对系统，则在计算上做不到。
现在，第二个示例，请对文档签名以证明其真实性。签名算法使用密钥对中的私钥来处理要签名的文档的加密哈希：
假设 Alice 以数字方式签署了发送给 Bob 的合同。然后，Bob 可以使用 Alice 密钥对中的公钥来验证签名：
假若没有 Alice 的私钥，就无法轻松伪造 Alice 的签名：因此，Alice 有必要保密她的私钥。
在 client 程序中，除了数字证书以外，这些安全性都没有明确展示。下一篇文章使用使用 OpenSSL 实用程序和库函数的示例填充更多详细的信息。
同时，让我们看一下 OpenSSL 命令行实用程序：特别是在 TLS 握手期间检查来自 Web 服务器的证书的实用程序。调用 OpenSSL 实用程序可以使用 openssl 命令，然后添加参数和标志的组合以指定所需的操作。
看看以下命令：
该输出是组成 加密算法套件(cipher suite)()的相关算法的列表。下面是列表的开头，加了澄清首字母缩写词的注释：
下一条命令使用参数 s_client 将打开到 www.google.com 的安全连接，并在屏幕上显示有关此连接的所有信息：
诸如 Google 之类的主要网站通常会发送多个证书进行身份验证。
输出以有关 TLS 会话的摘要信息结尾，包括加密算法套件的详细信息：
client 程序中使用了协议 TLS 1.2，Session-ID 唯一地标识了 openssl 实用程序和 Google Web 服务器之间的连接。Cipher 条目可以按以下方式进行解析：
加密算法套件正在不断发展中。例如，不久前，Google 使用 RC4 流加密算法（RSA 的 Ron Rivest 后来开发的 Ron’s Cipher 版本 4）。 RC4 现在有已知的漏洞，这大概部分导致了 Google 转换为 AES128。
我们通过安全的 C Web 客户端和各种命令行示例对 OpenSSL 做了首次了解，使一些需要进一步阐明的主题脱颖而出。 下一篇文章会详细介绍 ，从加密散列开始，到对数字证书如何应对密钥分发挑战为结束的更全面讨论。
via: https://opensource.com/article/19/6/cryptography-basics-openssl-part-1
作者： Marty Kalin 选题： lujun9972 译者： wxy 校对： wxy
⑸ TLS 详解
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 需要服务器和客户端都支持，属于一个扩展字段，占用服务器资源很少。
⑹ Hello，密码学：第三部分，公钥密码（非对称密码）算法
在 《Hello，密码学：第二部分，对称密码算法》 中讲述了对称密码的概念，以及DES和AES两种经典的对称密码算法原理。既然有对称密码的说法，自然也就有非对称密码，也叫做公钥密码算法。 对称密码和非对称密码两种算法的本质区别在于，加密密钥和解密密钥是否相同 ：
公钥密码产生的初衷就是为了解决 密钥配送 的问题。
Alice 给远方的 Bob 写了一封情意慢慢的信，并使用强悍的 AES-256 进行了加密，但她很快就意识到，光加密内容不行，必须要想一个安全的方法将加密密钥告诉 Bob，如果将密钥也通过网络发送，很可能被技术高手+偷窥癖的 Eve 窃听到。
既要发送密钥，又不能发送密钥，这就是对称密码算法下的“密钥配送问题” 。
解决密钥配送问题可能有这样几种方法：
这种方法比较高效，但有局限性：
与方法一不同，密钥不再由通信个体来保存，而由密钥分配中心（KDC）负责统一的管理和分配。 双方需要加密通信时，由 KDC 生成一个用于本次通信的通信密钥交由双方，通信双方只要与 KDC 事先共享密钥即可 。这样就大大减少密钥的存储和管理问题。
因此，KDC 涉及两类密钥：
领略下 KDC 的过程：
KDC 通过中心化的手段，确实能够有效的解决方法一的密钥管理和分配问题，安全性也还不错。但也存在两个显着的问题：
使用公钥密睁衡码，加密密钥和解密密钥不同，只要拥有加密密钥，所有人都能进行加密，但只有拥有解密密钥的人才能进行解密。于是就出现了这个过程：
密钥配送的问题天然被解决了。当然，解密密钥丢失而导致信息泄密，这不枯脊属于密钥配送的问题。
下面，再详细看下这个过程。
公钥没早渗密码流程的核心，可以用如下四句话来概述：
既然加密密钥是公开的，因此也叫做 “公钥（Public Key）” 。
既然解密密钥是私有的，因此也叫做 “私钥（Private Key） 。
公钥和私钥是一一对应的，称为 “密钥对” ，他们好比相互纠缠的量子对， 彼此之间通过严密的数学计算关系进行关联 ，不能分别单独生成。
在公钥密码体系下，再看看 Alice 如何同 Bob 进行通信。
在公钥密码体系下，通信过程是由 Bob 开始启动的：
过程看起来非常简单，但为什么即使公钥被窃取也没有关系？这就涉及了上文提到的严密的数学计算关系了。如果上一篇文章对称密钥的 DES 和 AES 算法进行概述，下面一节也会对公钥体系的数学原理进行简要说明。
自从 Diffie 和 Hellman 在1976年提出公钥密码的设计思想后，1978年，Ron Rivest、Adi Shamir 和 Reonard Adleman 共同发表了一种公钥密码算法，就是大名鼎鼎的 RSA，这也是当今公钥密码算法事实上的标准。其实，公钥密码算法还包括ElGamal、Rabin、椭圆曲线等多种算法，这一节主要讲述 RSA 算法的基本数学原理。
一堆符号，解释下，E 代表 Encryption，D 代表 Decryption，N 代表 Number。
从公式种能够看出来，RSA的加解密数学公式非常简单（即非常美妙）。 RSA 最复杂的并非加解密运算，而是如何生成密钥对 ，这和对称密钥算法是不太一样的。 而所谓的严密的数学计算关系，就是指 E 和 D 不是随便选择的 。
密钥对的生成，是 RSA 最核心的问题，RSA 的美妙与奥秘也藏在这里面。
1. 求N
求 N 公式：N = p × q
其中， p 和 q 是两个质数 ，而且应该是很大又不是极大的质数。如果太小的话，密码就容易被破解；如果极大的话，计算时间就会很长。比如 512 比特的长度（155 位的十进制数字）就比较合适。
这样的质数是如何找出来的呢？ 需要通过 “伪随机数生成器（PRNG）” 进行生成，然后再判断其是否为质数 。如果不是，就需要重新生成，重新判断。
2. 求L
求 L 公式：L = lcm(p-1, q-1)
lcm 代表 “最小公倍数（least common multiple）” 。注意，L 在加解密时都不需要， 仅出现在生成密钥对的过程中 。
3. 求E
E 要满足两个条件：
1）1 < E < L
2）gcd(E,L) = 1
gcd 代表 “最大公约数（greatest common divisor）” 。gcd(E,L) = 1 就代表 “E 和 L 的最大公约数为1，也就是说， E 和 L 互质 ”。
L 在第二步已经计算出来，而为了找到满足条件的 E， 第二次用到 “伪随机数生成器（PRNG）” ，在 1 和 L 之间生成 E 的候选，判断其是否满足 “gcd(E,L) = 1” 的条件。
经过前三步，已经能够得到密钥对种的 “公钥：{E, N}” 了。
4. 求D
D 要满足两个条件：
1）1 < D < L
2）E × D mod L = 1
只要 D 满足上面的两个条件，使用 {E, N} 进行加密的报文，就能够使用 {D, N} 进行解密。
至此，N、L、E、D 都已经计算出来，再整理一下
模拟实践的过程包括两部分，第一部分是生成密钥对，第二部分是对数据进行加解密。为了方便计算，都使用了较小的数字。
第一部分：生成密钥对
1. 求N
准备两个质数，p = 5，q = 7，N = 5 × 7 = 35
2. 求L
L = lcm(p-1, q-1) = lcm (4, 6) = 12
3. 求E
gcd(E, L) = 1，即 E 和 L 互质，而且 1 < E < L，满足条件的 E 有多个备选：5、7、11，选择最小的 5 即可。于是，公钥 = {E, N} = {5, 35}
4. 求D
E × D mod L = 1，即 5 × D mod 12 = 1，满足条件的 D 也有多个备选：5、17、41，选择 17 作为 D（如果选择 5 恰好公私钥一致了，这样不太直观），于是，私钥 = {D, N} = {17, 35}
至此，我们得到了公私钥对：
第二部分：模拟加解密
明文我们也使用一个比较小的数字 -- 4，利用 RSA 的加密公式：
密文 = 明文 ^ E mod N = 4 ^ 5 mod 35 = 9
明文 = 密文 ^ D mod N = 9 ^ 17 mod 35 = 4
从这个模拟的小例子能够看出，即使我们用了很小的数字，计算的中间结果也是超级大。如果再加上伪随机数生成器生成一个数字，判断其是否为质数等，这个过程想想脑仁儿就疼。还好，现代芯片技术，让计算机有了足够的运算速度。然而，相对于普通的逻辑运算，这类数学运算仍然是相当缓慢的。这也是一些非对称密码卡/套件中，很关键的性能规格就是密钥对的生成速度
公钥密码体系中，用公钥加密，用私钥解密，公钥公开，私钥隐藏。因此：
加密公式为：密文 = 明文 ^ E mod N
破译的过程就是对该公式进行逆运算。由于除了对明文进行幂次运算外， 还加上了“模运算” ，因此在数学上， 该逆运算就不再是简单的对数问题，而是求离散对数问题，目前已经在数学领域达成共识，尚未发现求离散对数的高效算法 。
暴力破解的本质就是逐个尝试。当前主流的 RSA 算法中，使用的 p 和 q 都是 1024 位以上，这样 N 的长度就是 2048 位以上。而 E 和 D 的长度和 N 差不多，因此要找出 D，就需要进行 2048 位以上的暴力破解。即使上文那个简单的例子，算出（ 蒙出 ） “9 ^ D mod 35 = 4” 中的 D 也要好久吧。
因为 E 和 N 是已知的，而 D 和 E 在数学上又紧密相关（通过中间数 L），能否通过一种反向的算法来求解 D 呢？
从这个地方能够看出，p 和 q 是极为关键的，这两个数字不泄密，几乎无法通过公式反向计算出 D。也就是说， 对于 RSA 算法，质数 p 和 q 绝不能被黑客获取，否则等价于交出私钥 。
既然不能靠抢，N = p × q，N是已知的，能不能通过 “质因数分解” 来推导 p 和 q 呢？或者说， 一旦找到一种高效的 “质因数分解” 算法，就能够破解 RSA 算法了 。
幸运的是，这和上述的“离散对数求解”一样，当下在数学上还没有找到这种算法，当然，也无法证明“质因数分解”是否真的是一个困难问题 。因此只能靠硬算，只是当前的算力无法在可现实的时间内完成。 这也是很多人都提到过的，“量子时代来临，当前的加密体系就会崩溃”，从算力的角度看，或许如此吧 。
既不能抢，也不能算，能不能猜呢？也就是通过 “推测 p 和 q 进行破解” 。
p 和 q 是通过 PRNG（伪随机数生成器）生成的，于是，又一个关键因素，就是采用的 伪随机数生成器算法要足够随机 。
随机数对于密码学极为重要，后面会专门写一篇笔记 。
前三种攻击方式，都是基于 “硬碰硬” 的思路，而 “中间人攻击” 则换了一种迂回的思路，不去尝试破解密码算法，而是欺骗通信双方，从而获取明文。具体来说，就是： 主动攻击者 Mallory 混入发送者和接收者之间，面对发送者伪装成接收者，面对接收者伪装成发送者。
这个过程可以重复多次。需要注意的是，中间人攻击方式不仅能够针对 RSA，还可以针对任何公钥密码。能够看到，整个过程中，公钥密码并没有被破译，密码体系也在正常运转，但机密性却出现了问题，即 Alice 和 Bob 之间失去了机密性，却在 Alice 和 Mallory 以及 Mallory 和 Bob 之间保持了机密性。即使公钥密码强度再强大 N 倍也无济于事。也就是说，仅仅依靠密码算法本身，无法防御中间人攻击 。
而能够抵御中间人攻击的，就需要用到密码工具箱的另一种武器 -- 认证 。在下面一篇笔记中，就将涉及这个话题。
好了，以上就是公钥密码的基本知识了。
公钥密码体系能够完美的解决对称密码体系中 “密钥配送” 这个关键问题，但是抛开 “中间人攻击” 问题不谈，公钥密码自己也有个严重的问题：
公钥密码处理速度远远低于对称密码。不仅体现在密钥对的生成上，也体现在加解密运算处理上。
因此，在实际应用场景下，往往会将对称密码和公钥密码的优势相结合，构建一个 “混合密码体系” 。简单来说： 首先用相对高效的对称密码对消息进行加密，保证消息的机密性；然后用公钥密码加密对称密码的密钥，保证密钥的机密性。
下面是混合密码体系的加解密流程图。整个体系分为左右两个部分：左半部分加密会话密钥的过程，右半部分是加密原始消息的过程。原始消息一般较长，使用对称密码算法会比较高效；会话密钥一般比较短（十几个到几十个字节），即使公钥密码算法运算效率较低，对会话密钥的加解密处理也不会非常耗时。
着名的密码软件 PGP、SSL/TLS、视频监控公共联网安全建设规范（GB35114） 等应用，都运用了混合密码系统。
好了，以上就是公钥密码算法的全部内容了，拖更了很久，以后还要更加勤奋一些。
为了避免被傻啦吧唧的审核机器人处理，后面就不再附漂亮姑娘的照片（也是为了你们的健康），改成我的摄影作品，希望不要对收视率产生影响，虽然很多小伙儿就是冲着姑娘来的。
就从喀纳斯之旅开始吧。
⑺ 加密算法套件怎么根据需要选择
SSL 支持各种各样的加密套件，这些加密套件指定一组供连接使用的算法。这些算法的
强度从非常弱的可出口型（如40 位模式的RC4）到强度非常之高的（希望是这样）如3DES。
此外，非对称密钥对可以使用一定范围长度的密钥。SSL 连接的安全自然而然就全部有赖于
它所使用的加密算法的安全，因此应选择与你的数据价值相当的加密套件。
为了做到这一点，就要根据你的应用程序所能支持的对加密套件**加以限制。由于客
户端与服务器必须就共同的加密套件达成一致才能进行通信，所以这样将确保你能获得相应
级别的安全。然而，一种可能的副作用就是服务器与客户端可能没有共同的算法**，因而
也就无法进行通信。因此，通常最好的策略是允许提供超过可接受的最低安全级别的所有加
密套件，而不只是专选支持最高强度的加密算法。
⑻ 如何查看本机能够支持的https加密算法套件
HTTPS加密算法，来自于签发机构的SSL证书CSR文件，也就是说签发完毕的证书加密算法，就一定定向了，您可以打开这个网站，就说明就是支持，算法：sha256 加密位数：2048，是证书常见的标准，你可以打开网络知道，就说明支持的。
⑼ 常见加密算法原理及概念
在安全领域，利用密钥加密算法来对通信的过程进行加密是一种常见的安全手段。利用该手段能够保障数据安全通信的三个目标：
而常见的密钥加密算法类型大体可以分为三类：对称加密、非对称加密、单向加密。下面我们来了解下相关的算法原理及其常见的算法。
对称加密算法采用单密钥加密，在通信过程中，数据发送方将原始数据分割成固定大小的块，经过密钥和加密算法逐个加密后，发送给接收方；接收方收到加密后的报文后，结合密钥和解密算法解密组合后得出原始数据。由于加解密算法是公开的，因此在这过程中，密钥的安全传递就成为了至关重要的事了。而密钥通常来说是通过双方协商，以物理的方式传递给对方，或者利用第三方平台传递给对方，一旦这过程出现了密钥泄露，不怀好意的人就能结合相应的算法拦截解密出其加密传输的内容。
对称加密算法拥有着算法公开、计算量小、加密速度和效率高得特定，但是也有着密钥单一、密钥管理困难等缺点。
常见的对称加密算法有：
DES：分组式加密算法，以64位为分组对数据加密，加解密使用同一个算法。
3DES：三重数据加密算法，对每个数据块应用三次DES加密算法。
AES：高级加密标准算法，是美国联邦政府采用的一种区块加密标准，用于替代原先的DES，目前已被广泛应用。
Blowfish：Blowfish算法是一个64位分组及可变密钥长度的对称密钥分组密码算法，可用来加密64比特长度的字符串。
非对称加密算法采用公钥和私钥两种不同的密码来进行加解密。公钥和私钥是成对存在，公钥是从私钥中提取产生公开给所有人的，如果使用公钥对数据进行加密，那么只有对应的私钥才能解密，反之亦然。
下图为简单非对称加密算法的常见流程：
发送方Bob从接收方Alice获取其对应的公钥，并结合相应的非对称算法将明文加密后发送给Alice；Alice接收到加密的密文后，结合自己的私钥和非对称算法解密得到明文。这种简单的非对称加密算法的应用其安全性比对称加密算法来说要高，但是其不足之处在于无法确认公钥的来源合法性以及数据的完整性。
非对称加密算法具有安全性高、算法强度负复杂的优点，其缺点为加解密耗时长、速度慢，只适合对少量数据进行加密，其常见算法包括：
RSA ：RSA算法基于一个十分简单的数论事实：将两个大素数相乘十分容易，但那时想要对其乘积进行因式分解却极其困难，因此可以将乘积公开作为加密密钥，可用于加密，也能用于签名。
DSA ：数字签名算法，仅能用于签名，不能用于加解密。
DSS ：数字签名标准，技能用于签名，也可以用于加解密。
ELGamal ：利用离散对数的原理对数据进行加解密或数据签名，其速度是最慢的。
单向加密算法常用于提取数据指纹，验证数据的完整性。发送者将明文通过单向加密算法加密生成定长的密文串，然后传递给接收方。接收方在收到加密的报文后进行解密，将解密获取到的明文使用相同的单向加密算法进行加密，得出加密后的密文串。随后将之与发送者发送过来的密文串进行对比，若发送前和发送后的密文串相一致，则说明传输过程中数据没有损坏；若不一致，说明传输过程中数据丢失了。单向加密算法只能用于对数据的加密，无法被解密，其特点为定长输出、雪崩效应。常见的算法包括：MD5、sha1、sha224等等，其常见用途包括：数字摘要、数字签名等等。
密钥交换IKE（Internet Key Exchange）通常是指双方通过交换密钥来实现数据加密和解密，常见的密钥交换方式有下面两种：
1、公钥加密，将公钥加密后通过网络传输到对方进行解密，这种方式缺点在于具有很大的可能性被拦截破解，因此不常用；
2、Diffie-Hellman，DH算法是一种密钥交换算法，其既不用于加密，也不产生数字签名。DH算法的巧妙在于需要安全通信的双方可以用这个方法确定对称密钥。然后可以用这个密钥进行加密和解密。但是注意，这个密钥交换协议/算法只能用于密钥的交换，而不能进行消息的加密和解密。双方确定要用的密钥后，要使用其他对称密钥操作加密算法实际加密和解密消息。DH算法通过双方共有的参数、私有参数和算法信息来进行加密，然后双方将计算后的结果进行交换，交换完成后再和属于自己私有的参数进行特殊算法，经过双方计算后的结果是相同的，此结果即为密钥。
如：
在整个过程中，第三方人员只能获取p、g两个值，AB双方交换的是计算后的结果，因此这种方式是很安全的。
公钥基础设施是一个包括硬件、软件、人员、策略和规程的集合，用于实现基于公钥密码机制的密钥和证书的生成、管理、存储、分发和撤销的功能，其组成包括：签证机构CA、注册机构RA、证书吊销列表CRL和证书存取库CB。
PKI采用证书管理公钥，通过第三方可信任CA中心，把用户的公钥和其他用户信息组生成证书，用于验证用户的身份。
公钥证书是以数字签名的方式声明，它将公钥的值绑定到持有对应私钥的个人、设备或服务身份。公钥证书的生成遵循X.509协议的规定，其内容包括：证书名称、证书版本、序列号、算法标识、颁发者、有效期、有效起始日期、有效终止日期、公钥 、证书签名等等的内容。
CA证书认证的流程如下图，Bob为了向Alice证明自己是Bob和某个公钥是自己的，她便向一个Bob和Alice都信任的CA机构申请证书，Bob先自己生成了一对密钥对（私钥和公钥），把自己的私钥保存在自己电脑上，然后把公钥给CA申请证书，CA接受申请于是给Bob颁发了一个数字证书，证书中包含了Bob的那个公钥以及其它身份信息，当然，CA会计算这些信息的消息摘要并用自己的私钥加密消息摘要（数字签名）一并附在Bob的证书上，以此来证明这个证书就是CA自己颁发的。Alice得到Bob的证书后用CA的证书（自签署的）中的公钥来解密消息摘要，随后将摘要和Bob的公钥发送到CA服务器上进行核对。CA在接收到Alice的核对请求后，会根据Alice提供的信息核对Bob的证书是否合法，如果确认合法则回复Alice证书合法。Alice收到CA的确认回复后，再去使用从证书中获取的Bob的公钥加密邮件然后发送给Bob，Bob接收后再以自己的私钥进行解密。