❶ 什么是主密钥，有什么特点
主密钥是在一对用户之间的长期共享的秘密密钥，它往往作为生成会话密钥或密钥加密密钥的种子，实现这些密钥的分发和安全保护。而主密钥的分发则一般使用离线安全物理通道完成。
❷ 不同文档采用不同密钥加密保护,如何区分哪个密钥解密
有以下的几种方式，希望可以帮助到你：
1.基本密钥
基本密钥也称为初始密钥,通过用户选定或系统分配,大多数用密钥算法实现。基本密钥的使用期限一般比较长,可为数月、半年或一年等。一般用基本密钥来启动与控制系统的密钥生成器,产生一次通信过程使用的会话密钥。
2.会话密钥
2个通信终端用户在通信过程中用的密钥叫做会话密钥。会话密钥如果用于保护传输的数据,则叫做数据加密密钥;若用来对传输的文件进行保护,则称为文件加密密钥。使用会话密钥可不用太频繁地更换基本密钥,又由于会话密钥大多是临时的、动态的,且使用的时间较短,这样就限制了攻击者能截获的同一密钥加密的密文量,进而加大了密码分析的难度,有助于密钥的安全与管理。
3.密钥加密密钥
用来对要传送的会话密钥等其他密钥加密的密钥叫密钥加密密钥,也叫次主密钥或二级密钥。通信网中的每个节点均需配备这样的密钥,且各节点的密钥加密密钥均不同,在主机与主机之间以及主机与各终端之间传送会话密钥时,都需要有相应的密钥加密密钥来保护。
4.主密钥
主密钥是对密钥加密密钥实施加密的一种密钥,主密钥通常被严格保护,保存于网络中心、主节点和主处理机中。它通常用手工分配,或是在初始阶段通过过程控制在物理或电子隔离情况下安装。
❸ 什么是会话密钥
主密钥（master?key）是被客户机和服务器用于产生会话密钥的一个密钥。这个主密钥被用于产生客户端读密钥，客户端写密钥，服务器读密钥，服务器写密钥。主密钥能够被作为一个简单密钥块输出
会话密钥是指：当两个端系统希望通信，他们建立一条逻辑连接。在逻辑连接持续过程中，所以用户数据都使用一个一次性的会话密钥加密。在会话和连接结束时，会话密钥被销毁。
❹ 密码学笔记
别人用A的公钥加密传输的信息，只有A的私钥可以解密。保证了传输的信息的安全性。
A用A的私钥加密的信息，别人用A的公钥才可以解密。可以证明这个信息一定是A传输而来的。
共享秘钥（对称加密）：速度快，但无法保证客户端与服务器之间传输时秘钥的安全性。
和公开密钥（非对称加密）：安全，速度慢。
一、客户端请求SSL（安全套接层）通信，报文中包含自己支持的SSL版本、加密算法等。
二、服务器应答，附带自己的公钥证书，协商定好的SSL版本、加密组件。
三、客户端根据自己本地的收信任的CA公钥，解封服务器公钥证书，得到服务器公钥。客户端生成一个随机码序列，用服务器公钥加密后，发回服务器。
四、服务器用私钥解密后，再加密将字符串传回客户端。
五、客户端确认服务器身份后，生成对称加密算法和共享秘钥，使用服务器公钥加密后，传给服务器。
六、此后，双方使用对称加密算法加密数据，进行传输。
上面过程中，一二用于获得合法的服务器公钥，三四用于确认服务器是否为真正私钥持有者（因为，服务器公钥谁都可以得到）。
使用与明文比特序列一样长的，真正的随机数序列，进行加密，绝对安全，因为穷举破译后能得到整个秘钥空间，毫无意义。
以分组为单位进行处理的密码算法称为 分组密码。
采用 Feistel网络。
以 64 bit 为一个加密单位，首先分成两部分，各32 bit 。
加密过程持续数轮，每轮中，使用子秘钥与右侧数据经过轮函数生成一个序列，然后与左侧做 XOR 。
每轮结束后，左右两侧交换。
加解密结构相同，轮数任意，函数任意。
使用秘钥1、2、3对明文进行加密、解密、加密三个过程，称为三重DES。
解密过程是为了兼容老版DES，如果1、2、3秘钥相同，则成为了普通DES。
1、3秘钥相同，2不同时，称为DES-EDE2 。
1、2、3秘钥不同，称为DES-EDE3 。
采用的是 Rijndael 算法，SPN结构。
输入分组为 128bit（16字节），秘钥长度可以以 32bit 为单位，在128~256bit之间选择。
该算法由多轮构成，10~14轮。
一轮中：
SubBytes，按字节，将输入分开，以每个字节为索引，查表找值，替换。
ShiftRows（平移行），按字节，打乱上面的输出。
MixColumns （混合列），按4个字节，比特运算。
与轮秘钥进行 XOR 。
分组密码：每次处理，特定长度的一块数据。
流密码：对数据流，连续处理，需要保持内部状态，记录进度。
明文分组加密后，直接成为，密文分组。
特点：攻击者无需破译，即可操纵明文。
明文分组，与前一个密文分组XOR，加密得到自己的密文分组。
第一个分组的前一个密文分组，由 初始化向量（随机比特序列） 代替。
加密时，需要从头开始。因为需要与密文分组做 XOR 。
解密时，对密文分组解密，直接与密文分组 XOR 即可。
同样的明文分组，密文值可以不相等。
密文分组可以损坏，影响部分。
密文分组比特缺失，影响全部。
前一个密文分组，通过加密算法得到一个比特序列，称为 密钥流 。
明文分组，与密钥流 XOR，得到自己的密文分组。
解密时，加密算法对密文分组进行加密，得到密钥流，与密文 XOR 可得到明文。
重复攻击：假设秘钥相同。发送 4 个分组，攻击者保存了后面3个。转天，你又发送了 4 个分组，攻击者将你后面三个替换，接收方解密后，只有 2 号分组有错。
对于每个分组，初始化向量加密后，得到密钥流。明文与密钥流 XOR 后，得到密文。
速度快，密钥流可以提前生成，或者，生成秘钥过程可以和 XOR 运算并行。
对每个计数器加密得到密钥流。密钥流与明文分组 XOR ，得到密文分组。
计数器生成的数，由 一个随机序列 nonce + 从1开始的递增数字 组成。
对每个分组，计数器递增后，加密，得到密钥流。
能够以任意顺序处理分组，因为加密时需要的初始数字序列能够计算出来。
为了确保安全，有地理局限，与不同的人通信需要不同密钥，共享繁琐。
每个员工有自己的密钥，密钥分配中心使用个人密钥，包裹临时会话密钥，分配给各个员工使用。
密文=明文的E次方 MOD N
E 和 N 是RSA加密用的密钥，也就是说，E 和 N 的组合就是公钥。
明文=密文的D次方 MOD N
D 和 N 的组合就是私钥。
寻两个很大的质数 p 和 q，相乘得到 N
L为 p-1 和 q-1 的最小公倍数
随机数生成器，不停地生成数字，直到满足如下条件：
1 < E < L
E 和 L 的最大公约数为 1
根据 E ，计算 D
1 < E < L
E × D MOD L = 1
保证 E 与 L 互质，则 D 一定存在。
求对数很容易，求 离散对数 很困难
对一个大数字进行质因数分解，人类未找到高效算法
利用了 MOD N下，求离散对数的困难度
加密后，密文长度翻倍
利用了 MOD N下，求平方根的困难度
密码实现通过 对椭圆曲线上的特定点进行特殊乘法。
利用了该种乘法的逆运算非常困难这一特性
单向散列函数 又称为，消息摘要函数、哈希函数、杂凑函数
输入的消息 又称为，原像
散列值 又称为，消息摘要、指纹
完整性 又称为，一致性
根据任意消息，计算出的散列值长度，固定
用时短
消息不同，散列值不同
具备单向性
MD是消息摘要的意思
可以产生 128bit 的散列值，但它们的抗碰撞性已被攻破
SHA-1散列值长度为 160bit，强碰撞性已被攻破
其余的统称为 SHA-2，散列值长度为各自后面的数字
欧盟版本
第三代 SHA
消息上限 2^64 bit。
消息长度需要是 512bit 的整数倍。这样的 512比特 称为一个输入分组。
过程：
消息末尾添加 1
然后添加 0，直到最后一个分组的 448比特 的位置
最后 64比特 需要保存原是消息的长度
对每个分组计算 80 个 32bit 的值。
过程：
将 512bit 分成 32bit × 16组，称为 W0~W15
从15组中按规律取4组，进行 XOR 运算，结果循环左移 1 位，得到另外一组。如此反复，得到总共 80 组。
ABCDE 五个 32bit 的缓冲区，保存了 160bit 的消息内部状态。
内部状态与每个 512bit 的输入分组混合，一共 80 个步骤。
最终得到 160bit 的最终内部状态。
暴力破解：暴力寻找与 1亿元合同 散列值相同的文件
生日攻击：准备两份 散列值相同的 1亿元合同
可以辨别 篡改，无法辨别 伪装，因此还需要 认证技术
认证技术包括 消息验证码 和 数字签名
消息验证码：可以向通信对象保证消息不被篡改
数字签名：可以向任何人保证通信对象不被篡改
message authentication code，简称 MAC。
相当于 使用共享密钥的单向散列函数
SWIFT：负责银行间的交易，公钥密码使用前，都是人工配送密钥的。
IPsec：对IP协议增加安全性，采用的是消息认证码
SSL/TLS：网上购物等场景中所用协议。
过程：
密钥填充 至单向散列函数要求的输入分组大小
填充后的密钥 与 ipad（16进制的36不断循环）XOR，得到ipadkey
与 消息 组合，计算散列值
填充后的密钥 与 opad（16进制的5C不断循环）XOR，得到opadkey
与 上面得到的散列值 组合，计算新的散列值，为最终的MAC值
对第三方证明
防止否认
因为知晓密钥的只有两个当事人，第三者无法确定能拿到合法的密钥，无法自己计算合法MAC值
RSA：利用质因数分解难度的那个
ElGamal：利用求离散对数的困难度的那个，数字签名有漏洞，现仅用于公钥密码
DSA：Schnorr算法与ElGamal方式的变体，只能用于数字签名
Rabin：利用了求MOD N中平方根的困难度，可用于数字签名和公钥密码
例如，verisign公司的认证业务分为三个等级，等级越高，越严格
ITU 国际电信联盟和 ISO 国际标准化组织制定的 X.509 规范如下
大体包含以下内容：
签名前的证书——签名对象的各种消息
数字签名算法——签名时所用的算法
数字签名——得到的数字签名
PKI ：为了能有效使用公钥而制定的一系列规范和规格
PKI 的组成要素如下
两种方法：一种是由认证机构生成，一种是由 PKI 用户自行生成
认证机构有一个 CRL（认证作废清单），具有数字签名，记载了已经作废的证书的编号。
认证时，从上（根证书）往下
对于密钥，关键的是 密钥空间的大小
DES 的密钥 实质长度（即，除去校验错误的比特后的长度）7字节
DES-EDE2 的实质长度 14字节，DES-EDE3 的实质长度 21字节
AES 的密钥长度可以从 128、192 和 256bit 当中选
会话密钥：每次通信中，仅使用一次的密钥
主密钥：一直被重复使用的密钥
CEK：Contents Encrypting Key
KEK: Key Encrypting Key
各个步骤中的密钥管理方法
两种方法：
用随机数生成密钥：使用具备不可预测性的伪随机数生成器生成随机数
用口令生成密钥：一般使用，口令 + 一串称为 salt 的随机数，得到他们的散列值作为密钥（这种方法称为：基于口令的密码）
事先共享
秘钥分配中心
使用公钥密钥
Diffie-Hellman 密钥交换
密钥更新：一种提高通信机密性的技术
原理：
使用 共享密钥 进行通信时，定期改变密钥。
双方使用同样的方法，对当前密钥求 散列值，并作为下一个密钥
优点：
后向安全：防止破译过去的内容
对密钥进行加密，然后保存
意义：
同时对多个密钥进行加密，可以减少保存密钥的数量
步骤：
P 为非常大的质数，G 为 P 的 生成元
目的为，将 随机数 A 的信息 含蓄地发给了 B
目的为，将 随机数 B 的信息 含蓄地发给了 A
计算方法：密钥 = （G ^ B MOD P) ^ A MOD P = G^(A × B) MOD P
计算方法：密钥 = （G ^ A MOD P) ^ B MOD P = G^(A × B) MOD P
对于一个质数 P ，只有它的生成元在进行 G ^ x MOD P 时，结果能够覆盖 0 ~ P-1 的所有数字
用途：用于安全的保存密钥
由来：
一 生成会话密钥 CEK ，加密消息
二 需要保密 会话密钥CEK，使用 密钥加密密钥KEK 对会话密钥进行保密
三 现在需要保密 KEK 这个密钥，选择使用口令生成这个 KEK
保密的问题最终都归结为了 安全保存密钥，然而我们记不住密钥。
于是，选择单向散列函数对口令生成散列值，作为密钥。
这个密钥无需保存，我们可以通过口令随时求得，口令也无法被反向推出，且口令方便记忆。
顺带，为了防止字典攻击，生成口令散列值时，需要使用 口令 + salt（随机数序列）
事先 已准备好 候选列表 的攻击方法
随机性
不可预测性
不可重见性
这三个性质，越往下越严格。分别称为：
弱伪随机数（不可用于密码学）
强伪随机数
真随机数
伪随机数生成器是公开的，种子是保密的。
确保种子的不可预测性，更加容易些。
种子是用来对伪随机数生成器的 内部状态进行初始化 的
R1 = （A × R0 + C) MOD M
数据有限，不能用于密码学
单向散列函数的单向性是支撑伪随机数序列不可预测性的基础
利用 AES 等对称密钥对内部状态进行加密
从当前时间开始，利用加密算法 求得加密后的时间的掩码 （因为密钥未知，别人无法推测出掩码信息）
与内部状态 XOR，加密后输出， 得到伪随机数序列
对伪随机数序列加密后，作为 下一个内部状态
针对极端情况的密码软件，具有全部功能。
TLS 由 TLS 记录协议 和 TLS 握手协议 叠加而成。
负责消息的 加密、压缩 和 认证
商定 客户端和服务器 所用的加密算法和密钥
负责 传递 变更密码的信号
发生错误时 通知对方
传输数据
❺ 如何保证钱包私钥安全
对于数字货币钱包来说，它并不是装钱的，而是装密钥的工具，准确来说，就是装私钥的工具。有了私钥就可以拥有根据其对应公钥计算出的地址上的数字货币的支配权。
作为钱包开发者，如何存储和使用用户私钥便是钱包安全的关键所在。
下面是使用imToken钱包App创建钱包的截图。从截图上可以清楚的看到我们在钱包的时候需要输入密码来保护私钥。那这个私钥究竟是如何被保护的呢？私钥的生成和输入的密码有没有关系呢？
这里一般有两种误解：
如果钱包应用开发者真的这么做的话，估计大家每天都是排着队丢币了 :)。
你想啊，如果是第一种情况，那如果两个人用同样的密码不就可以互相看到对方钱包了么。
如果是第二种情况，在你输入密码进入钱包应用后，私钥就要被加载并驻留在内存里。你在网上搜一下“从内存提取密码工具”，保证可以搜到一大把。另外一个风险是，用户输入的密码都不是太长并且很多时候有规律可循，这样当加密后的私钥数据泄漏后，黑客通过暴力破解结合彩虹表等工具将私钥破解的几率还是比较高的。
事实上，私钥的生成永远和你输入的密码没有半毛钱关系，要么是随机生成，要么是根据助记符（一串随机生成的英文或其它语言词组）生成，保证每个人的私钥都是唯一的。
私钥的加密过程一般来说是下面这样的：
第一步：钱包应用会生成一个32字节随机数，我们称之为主密钥。
第二步：使用用户输入的密码对主密钥加密，生成主密钥密文。
第三步：使用主密钥对钱包私钥进行加密，生成私钥密文。
第四步：清除主密钥和私钥，保留主密钥密文和私钥密文。
你可以会有疑问，这样黑客拿到密文后先暴力破解主密钥，再破解私钥不也很容易么？其实在具体实现的时候，每个密文在生成的时候不只是用输入的密码，还有相应的密文生成参数，想通过密文和密码直接解密得到明文没那么容易的。
从上一部分的解释我们知道，钱包应用里保存的是主密钥密文和私钥密文。
当我们登录钱包后，钱包应用会通过我们输入的密码对主密钥密文解密，将解密后的主密钥驻留内存。
当我们进行转账等需要私钥签名的操作时，通过主密钥解密私钥密文得到私钥，使用后立即将私钥从内存清除。
当我们需要修改密码时，实际上只是修改了主密钥密文，并不会触碰私钥相关部分。
这样，基本上将私钥明文暴露的几率降到最低，最大限度的保证私钥的安全。
还有疑问？欢迎加入我的知识星球，尽我所能为你答疑解惑。
❻ 什么是主密钥
KDC和每个实体之间共享一个秘密密钥，这个密钥成为主密钥。
❼ 对称密码管理中密钥分为高级密钥中级密钥和初级密钥对吗
对称密码管理中密钥分为高级密钥、中级密钥和初级密钥，是不对的。
对称密码管理中密钥分为初级密钥、二级密钥、三级密钥、高级密钥。
对称密码术早已被人们使用了数千年，它有各种形式从简单的替换密码到较复杂的构造方式。
❽ 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 需要服务器和客户端都支持，属于一个扩展字段，占用服务器资源很少。
❾ 密码技术（十一）之密钥
——秘密的精华
在使用对称密码、公钥密码、消息认证码、数字签名等密码技术使用，都需要一个称为 密钥 的巨大数字。然而，数字本身的大小并不重要，重要的是 密钥空间的大小 ，也就是可能出现的密钥的总数量，因为密钥空间越大，进行暴力破解就越困难。密钥空间的大小是由 密钥长度 决定的。
对称密码DES的密钥的实质长度为56比特（7个字节）。
例如，
一个DES密钥用二进制可以表示为：
01010001 11101100 01001011 00010010 00111101 01000010 00000011
用十六进制则可以表示为：
51 EC 4B 12 3D 42 03
而用十进制则可以表示为：
2305928028626269955
在对称密码三重DES中，包括使用两个DES密钥的DES-EDE2和使用三个DES密钥的DES-EDE3这两种方式。
DES-EDE2的密钥长度实质长度为112比特（14字节），比如：
51 EC 4B 12 3D 42 03 30 04 D8 98 95 93 3F
DES-EDE3的密钥的实质长度为168比特（21字节），比如：
51 EC 4B 12 3D 42 03 30 04 D8 98 95 93 3F 24 9F 61 2A 2F D9 96
对称密码AES的密钥长度可以从128、192和256比特中进行选择，当密钥长度为256比特时，比如：
51 EC 4B 12 3D 42 03 30 04 D8 98 95 93 3F 24 9F 61 2A 2F D9 96
B9 42 DC FD A0 AE F4 5D 60 51 F1
密钥和明文是等价的 。假设明文具有100万的价值，那么用来加密这段明文的密钥也就是具有100万元的价值；如果明文值1亿元，密钥也就值1亿元；如果明文的内容是生死攸关的，那么密钥也同样是生死攸关的。
在对称密码中，加密和解密使用同一个密钥。由于发送者和接收者需要共享密钥，因此对称密码又称为共享密钥密码。对称密码中所使用的密钥必须对发送者和接收者以外的人保密，否则第三方就能够解密了。
在消息认证码中，发送者和接收者使用共享的密钥来进行认证。消息认证码只能由持有合法密钥的人计算出来。将消息认证码附加在通信报文后面，就可以识别通信内容是否被篡改或伪装，由于“持有合法的密钥”就是发送者和接收者合法身份的证明，因此消息认证码的密钥必须对发送者以外的人保密，否则就会产生篡改和伪装的风险。
在数字签名中，签名生成和验证使用不同的密钥，只有持有私钥的本人才能够生成签名，但由于验证签名使用的是公钥，因此任何人都能够验证签名。
对称密码和公钥密码的密钥都是用于确保机密性的密钥。如果不知道用于解密的合法密钥，就无法得知明文的内容。
相对地，消息认证码和数字签名所使用的密钥，则是用于认证的密钥。如果不知道合法的密钥，就无法篡改数据，也无法伪装本人的身份。
当我们访问以https://开头的网页时，Web服务器和浏览器之间会进行基于SSL/TLS的加密通信。在这样的通信中所使用的密钥是仅限于本次通信的一次密钥，下次通信时就不能使用了，想这样每次通信只能使用一次的密钥称为 会话密钥 。
由于会话密钥只在本次通信中有效，万一窃听者获取了本次通信的会话密钥，也只能破译本次通信的内容。
虽然每次通信都会更换会话密钥，但如果用来生成密钥的伪随机数生成器品质不好，窃听者就有可能预测出下次生成会话密钥，这样就会产生通信内容被破译的风险。
相对于每次通信更换的会话密钥，一直被重复使用的密钥称为 主密钥 。
一般来说，加密的对象是用户直接使用的信息，这样的情况下所使用的密钥称为CEK(Contents Encryting Key，内容加密密钥)；相对地，用于加密密钥的密钥则称为KEK（Key Encryting Key，密钥加密密钥）。
在很多情况下，之前提到的会话密钥都是被作为CEK使用的，而主密钥则是被作为KEK使用的。
生成密钥的最好方法就是使用随机数，因为米哟啊需要具备不易被他人推测的性质。在可能的情况下最好使用能够生成密码学上的随机数的硬件设备，但一般我们都是使用伪随机数生成器这一专门为密码学用途设计的软件。
在生成密钥时，不能自己随便写出一些像“3F 23 52 28 E3....”这样的数字。因为尽管你想生成的是随机的数字，但无论如何都无法避免人为偏差，而这就会成为攻击者的目标。
尽管生成伪随机数的算法有很多种，但密码学用途伪随机生成器必须是专门针对密码学用途而设计的。例如，有一些伪随机数生成器可以用于游戏和模拟算法，尽管这些伪随机数生成器所生成的数列看起也是随机的，但只要不是专门为密码学用途设计的，就不能用来生成密钥，因为这些伪随机数生成器不具备不可预测性这一性质。
有时候我们也会使用人类的可以记住的口令（pasword或passphrase）来生成密钥。口令指的是一种由多个单词组成的较长的password。
严格来说，我们很少直接使用口令来作为密钥使用，一般都是将口令输入单向散列函数，然后将得到的散列值作为密钥使用。
在使用口令生成密钥时，为了防止字典攻击，需要在口令上附加一串称为盐（salt）的随机数，然后在将其输入单向散列函数。这种方法称为“基于口令的密码（Password Based Encryption，PBE）”。
在使用对称密码时，如何在发送者和接收者之间共享密钥是一个重要的问题，要解决密钥配送问题，可以采用事先共享密钥，使用密钥分配中心，使用公钥密码等方法，除了上述方法，之前还提到一种解决密钥配送的问题的方法称为Diffie-Hellman密钥交换。
有一种提供通信机密性的技术称为 密钥更新 （key updating），这种方法就是在使用共享密钥进行通信的过程中，定期更改密钥。当然，发送者和接收者必须同时用同样的方法来改变密钥才行。
在更新密钥时，发送者和接收者使用单向散列函数计算当前密钥的散列值，并将这个散列值用作新的密钥。简单说，就是 用当前密钥散列值作为下一个密钥 。
我们假设在通信过程中的某个时间点上，密钥被窃听者获取了，那么窃听者就可以用这个密钥将之后的通信内容全部解密。但是，窃听者却无法解密更新密钥这个时间点之前的内容，因为这需要用单向散列函数的输出反算出单向散列函数的输入。由于单向散列函数具有单向性，因此就保证了这样的反算是非常困难的。
这种防止破译过去的通信内容机制，称为 后向安全 （backward security）。
由于会话密钥在通信过程中仅限于一次，因此我们不需要保存这种秘密。然而，当密钥需要重复使用时，就必须要考虑保存密钥的问题了。
人类是 无法记住具有实用长度的密钥 的。例如，像下面这样一个AES的128比特的密钥，一般人是很难记住的。
51 EC 4B 12 3D 42 03 30 04 DB 98 95 93 3F 24 9F
就算勉强记住了，也只过不是记住一个密钥而已。但如果要记住多个像这样的密钥并且保证不忘记，实际上是非常困难的。
我们记不住密钥，但如果将密钥保存下来又可能会被窃取。这真是一个头疼的问题。这个问题很难得到彻底解决，但我们可以考虑一些合理的解决方法。
将密钥保存生文件，并将这个文件保存在保险柜等安全地方。但是放在保险柜里的话，出门就无法使用了。这种情况，出门时就需要随身携带密钥。而如果将密钥放在存储卡随身携带的话，就会产生存储卡丢失、被盗等风险。
万一密钥被盗，为了能够让攻击者花更多的时间才能真正使用这个密钥，我们可以使用将密钥加密后保存的方法，当然，要将密钥加密，必须需要另一个密钥。像这样用于密码加密的密钥，一般称为KEK。
对密钥进行加密的方法虽然没有完全解决机密性的问题，但在现实中却是一个非常有效地方法，因为这样做可以减少需要保管密钥的数量。
假设计算机上有100万个文件，分别使用不同的密钥进行加密生成100万个密文，结果我们手上就产生了100万个密钥，而要保管100万个密钥是很困难的。
于是，我们用一个密钥（KEK）将这100万个密钥进行加密，那么现在我们只要保管者一个KEK就可以了，这一个KEK的价值相当于签名的100万个密钥的价值的总和。
用1个密钥来代替多个密钥进行保管的方法，和认证机构的层级化非常相似。在后者中，我们不需要信任多个认证机构，而只需要信任一个根CA就可以了。同样的，我们也不需要确保多个密钥的机密性，而只需要确保一个KEK的机密性就可以了。
密钥的作废和生成是同等重要的，这是因为密钥和明文是等价的。
假设Alice向Bob发送了一封加密邮件。Bob在解密之后阅读了邮件的内容，这时本次通信所使用的密钥对于Alice和Bob来说就不需要了。不在需要的密钥必须妥善删除，因为如果被窃听者Eve获取，之前发送的加密邮件就会被解密。
如果密钥是计算机上的一个文件，那么仅仅删除这个文件是不足以删除密钥的，因为有一些技术能够让删除的文件“恢复”。此外，很多情况下文件的内容还会残留在计算机的内存中，因此必须将这些痕迹完全抹去。简而言之，要完全删除密钥，不但要用到密码软件，还需要在设计计算机系统时对信息安全进行充分的考虑
如果包含密钥的文件被误删或者保管密钥的笔记本电脑损坏了，会怎么样？
如果丢失了对称密钥密码的共享密钥，就无法解密密文了。如果丢失了消息认证码的密钥，就无法向通信对象证明自己的身份了。
公钥密码中，一般不太会发送丢失公钥的情况，因为公钥是完全公开的，很有可能在其他电脑上存在副本。
最大的问题是丢失公钥密码的私钥。如果丢失了公钥密码的私钥，就无法解密用公钥密码加密的密文了。此外，如果丢失了数字签名的私钥，就无法生成数字签名了。
Diffie-Hellman密钥交换（Diffie-Hellman key exchange）是1976年由Whitfield Diffie和Martin Hellman共同发明的一种算法。使用这种算法，通信双方仅通过交换一些可以公开的信息就能够生成共享秘密数字，而这一秘密数字就可以被用作对称密码的密钥。IPsec 中就使用了经过改良的Diffie-Hellman密钥交换。
2 Alice 生成一个随机数A
A是一个1 ~ P-2之间的整数。这个数是一个只有Alice知道的密码数字，没有必要告诉Bob，也不能让Eve知道。
Alice计算出的密钥=Bob计算出的密钥
在步骤1-7中，双方交换数字一共有4个，P、G、G A mod P 和 G B mod P。根据这4个数字计算出Alice和Bob的共享密钥是非常困难的。
如果Eve能欧知道A和B的任意一个数，那么计算G A*B 就很容易了，然而仅仅根据上面的4个数字很难求出A和B的。
根据G A mod P 计算出A的有效算法到现在还没有出现，这问题成为有限域(finite field) 的 离散对数问题 。
Diffie-Hellman密钥交换是利用了“离散对数问题”的复杂度来实现密钥的安全交换的，如果将“离散对数问题”改为“椭圆曲线上离散对数问题”，这样的算法就称为 椭圆曲线Diffie-Hellman 密钥交换。
椭圆曲线Diffie-Hellman密钥交换在总体流程上是不变的，只是所利用的数学问题不同而已。椭圆曲线Diffie-Hellman密钥交换能够用较短的密钥长度实现较高的安全性。
基于口令密码（password based encryption，PBE）就是一种根据口令生成密钥并用该密钥进行加密的方法。其中加密和解密使用同一个密钥。
PBE有很多种实现方法。例如RFC2898和RFC7292 等规范中所描述的PBE就通过java的javax.crypto包等进行了实现。此外，在通过密码软件PGP保存密钥时，也会使用PBE。
PBE的意义可以按照下面的逻辑来理解。
想确保重要消息的机制性。
↓
将消息直接保存到磁盘上的话，可能被别人看到。
↓
用密钥（CEK）对消息进行加密吧。
↓
但是这次又需要确保密钥（CEK）的机密性了。
↓
将密钥（CEK）直接保存在磁盘上好像很危险。
↓
用另一个密钥（KEK）对密钥进行加密（CEK）吧。
↓
等等！这次又需要确保密钥（KEK）的机密性了。进入死循环了。
↓
既然如此，那就用口令来生成密钥（KEK）吧。
↓
但只用口令容易遭到字典攻击
↓
那么就用口令和盐共同生成密钥（KEK）吧。
↓
盐可以和加密后的密钥（CEK）一切保存在磁盘上，而密钥（KEK）可以直接丢弃。
↓
口令就记在自己的脑子里吧。
PBE加密包括下列3个步骤：
盐是由伪随机数生成器生成的随机数，在生成密钥（KEK）时会和口令一起被输入单向散列函数。
密钥（KEK）是根据秘密的口令生成的，加盐好像没有什么意义，那么盐到底起到什么作用呢？
盐是用来防御字典攻击的 。字典攻击是一种事先进行计算并准备好候选密钥列表的方法。
我们假设在生成KEK的时候没有加盐。那么主动攻击者Mallory就可以根据字典数据事先生成大量的候选KEK。
在这里，事先是很重要的一点。这意味着Mallory可以在窃取到加密会话的密钥之前，就准备好了大量的候选KEK。当Mallory窃取加密的会话密钥后，就需要尝试将它解密，这是准备好了大量事先生成的候选KEK，就能够大幅度缩短尝试的时间，这就是 字典攻击 （dictionary attack）。
如果在生成KEK时加盐，则盐的长度越大，候选KEK的数量也会随之增大，事先生成的的候选KEK就会变得非常困难。只要Mallory还没有得到盐，就无法生成候选KEK。这是因为加盐之后，候选KEK的数量会变得非常巨大。
具有充足长度的密钥是无法用人脑记忆的。口令也是一样，我们也无法记住具有充足比特数的口令。
在PBE中，我们通过口令生成密钥（KEK），在用这个密钥来加密会话密钥（CEK）。由于通过口令生成的密钥（KEK）强度不如由伪随机数生成器生成的会话密钥（CEK），这就好像是将一个牢固的保险柜的钥匙放在了一个不怎么牢固的保险柜保管，因此在使用基于口令的密钥时，需要将盐和加密后的CEK通过物理方法进行保护。例如将盐和加密后的CEK保存到存储卡随身携带。
在生成KEK时，通过多次使用单向散列函数就可以提高安全性。例如，将盐和口令输入单向散列函数，进行1000次的散列函数所得到的散列值作为KEK来使用，是一个不错的方法。
像这样将单向散列函数进行多次迭代的方法称为 拉伸 （stretching）。
该系列的主要内容来自《图解密码技术第三版》
我只是知识的搬运工
文章中的插图来源于原着