#yyds干货盘点#哈希算法和多种加密算法综合使用

智慧并不产生于学历,而是来自对于知识的终生不懈的追求。这篇文章主要讲述#yyds干货盘点#哈希算法和多种加密算法综合使用相关的知识，希望能为你提供帮助。
1. 单向哈希算法哈希算法：也称为散列算法，将任意数据缩小成固定大小的“指纹”，称为digest，即摘要
特性：
任意长度输入，固定长度输出
若修改数据，指纹也会改变，且有雪崩效应，数据的一点微小改变，生成的指纹值变化非常大。无法从指纹中重新生成数据，即不要逆，具有单向性
功能：数据完整性
常见算法
md5: 128bits、sha1: 160bits、sha224 、sha256、sha384、sha512
常用工具
md5sum | sha1sum [ --check ] file
openssl、gpg
rpm -V

[root@c7-147 /]#cp /etc/fstab ./
[root@c7-147 /]#md5sum fstab
d7b5287b412cbf163a94ef80e2ebc2affstab
[root@c7-147 /]#mv fstab fstab.bak
[root@c7-147 /]#md5sum fstab.bak
d7b5287b412cbf163a94ef80e2ebc2affstab.bak
[root@c7-147 /]#echo > > fstab.bak
[root@c7-147 /]#md5sum fstab.bak#文件的内容变化，hash也发生变化
55515e84e76a213439b8b643efdceb2bfstab.bak
[root@c7-147 /]#

【#yyds干货盘点#哈希算法和多种加密算法综合使用】下载之前的话先记录hash值，然后到别的网站下载对比hash值

[root@c7-147 /]#sha256sum fstab.bak > sha256sum.txt
[root@c7-147 /]#cat sha256sum.txt
30d967d5475a1736c30130dda1309ab8160746bda18b7e585997ce48f348d237fstab.bak
[root@c7-147 /]#sha256sum -c sha256sum.txt
fstab.bak: OK
[root@c7-147 /]#echo > > fstab.bak
[root@c7-147 /]#sha256sum -c sha256sum.txt
fstab.bak: FAILED#追加内容马上报错
sha256sum: WARNING: 1 computed checksum did NOT match
[root@c7-147 /]#vim fstab.bak #修改以后马上
[root@c7-147 /]#sha256sum -c sha256sum.txt
fstab.bak: OK

2.数字签名?
RPM 文件完整性
rpm --verify package_name (or -V)
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat* rpm --checksig pakage_file_name (or -K)
3. 实现数据加密实现数据加密，无法验证数据完整性和来源
?

4. 实现数字签名不加密数据，可以保证数据来源的可靠性、数据的完整性和一致性
?
5. 综合加密和签名即实现数据加密，又可以保证数据来源的可靠性、数据的完整性和一致性方法1：PbSa[hash(data)]+data
?
方法2：对称keySa[hash(data)]+data+Pb(对称key)
?
6. 密MA交换密钥交换：IKE（ Internet Key Exchange ）
公钥加密：用目标的公钥加密对称密钥
DH (Deffie-Hellman)：生成对称（会话）密钥，由惠特菲尔德·迪菲（Bailey Whitfield Diffie）和马丁·赫尔曼（Martin Edward Hellman）在1976年发表
参看：??https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange??????
DH 实现过程：
A: g,p 协商生成公开的整数g, 大素数p
B: g,p
A:生成隐私数据:a (a< p)，计算得出 g^a%p，发送给B
B:生成隐私数据:b,(b< p)，计算得出 g^b%p，发送给A
A:计算得出 [(g^b%p)^a] %p = g^ab%p，生成为密钥
B:计算得出 [(g^a%p)^b] %p = g^ab%p，生成为密钥
7. 中间人攻JMan-in-the-middle，简称为 MITM，中间人
?
8. CA和证书

PKI：Public Key Infrastructure 公共密钥加密体系
签证机构：CA（Certificate Authority）
注册机构：RA
证书吊销列表：CRL
证书存取库：
X.509：定义了证书的结构以及认证协议标准
版本号
序列号
签名算法
颁发者
有效期限
主体名称
证书类型：
证书授权机构的证书
服务器证书
用户证书
获取证书两种方法：
自签名的证书：自已签发自己的公钥
使用证书授权机构：
生成证书请求（csr）
将证书请求csr发送给CA
CA签名颁发证书
?

根CA GlobalSIgn

9. 安全协议 SSL/TLSSSL：Secure Socket Layer，TLS: Transport Layer Security
SSL：Secure Socket Layer，TLS: Transport Layer Security
1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布
1995：SSL 2.0 Netscape 开发
1996：SSL 3.0
1999：TLS 1.0
2006：TLS 1.1 IETF(Internet工程任务组) RFC 4346，从2020年3月起，停止支持TLS 1.1及TLS 1.0版本安全协议，谷歌（Chrome）、Mozilla（Firefox）、微软（IE和Edge）、苹果（Safari）都会发布新版浏览器执行这个策略
2008：TLS 1.2 当前主要使用
2018：TLS 1.3
功能：
机密性
认证
完整性
重放保护
10. SSL/TLS组成
Handshake协议：包括协商安全参数和密ma套件、服务器身份认证（客户端身份认证可选）、密
钥交换
ChangeCipherSpec 协议：一条消息表明握手协议已经完成
Alert 协议：对握手协议中一些异常的错误提醒，分为fatal和warning两个级别，fatal类型错误会直接中断SSL链接，而warning级别的错误SSL链接仍可继续，只是会给出错误警告
Record 协议：包括对消息的分段、压缩、消息认证和完整性保护、加密等
11. TLS实现过程实现分为握手阶段和应用阶段
握手阶段(协商阶段):客户端和服务器端认证对方身份（依赖于PKI体系，利用数字证书进行身份认证），并协商通信中使用的安全参数、密ma套件以及主密钥。后续通信使用的所有密钥都是通过MasterSecret生成
应用阶段:在握手阶段完成后进入，在应用阶段通信双方使用握手阶段协商好的密钥进行安全通信
目前密钥交换 + 签名有三种主流选择：
RSA 密钥交换、RSA 数字签名
ECDHE 密钥交换、RSA 数字签名
ECDHE 密钥交换、ECDSA 数字签名
1实现方式
RSA 密钥交换、RSA 数字签名
?
1. Visitor给出协议版本号、一个客户端随机数（Client random），以及客户端支持的加密方法
2. Server确认双方使用的加密方法，以及一个服务器生成的随机数（Server random）
3. Server发送数字证书给Visitor
4. Visitor确认数字证书有效（查看证书状态且查询证书吊销列表），并使用信任的CA的公钥解密数字证书获得Server的公钥，然后生成一个新的46字节随机数（称为预备主密钥Pre-master secret），并使用Server的公钥加密预备主密钥发给Server
5. Server使用自己的私钥，解密Visitor发来的预备主密钥
6. Visitor和Server双方都具有了(客户端随机数+服务端随机数+预备主密钥)，它们两者都根据约定的加密方法，使用这三个随机数生成对称密钥——主密钥（也称为对话密钥session key），用来加密后续的对话过程
7. 在双方验证完session key的有效性之后，SSL握手机制就算结束了。之后所有的数据只需要使用“对话密钥”(此密钥并不是的session key，而是由其通过计算得到)加密即可，不再需要多余的加密机制
注意：
1.在SSL握手机制中，需要三个随机数（客户端随机数+服务端随机数+预备主密钥）
2.至始至终客户端和服务端只有一次非对称加密动作——客户端使用证书中获得的服务端公钥加密预备主密钥。
3.上述SSL握手机制的前提单向验证，无需验证客户端，如果需要验证客户端则可能需要客户端的证书或客户端提供签名等。
4.Server和Visitor通信，Server把数字证书发给Visitor，最关键的一点是Visitor要保证证书的有效性，通过查看证书状态并去CA的吊销列表查看Server的证书是否被吊销。只有Server的证书可用了，才保证了第一环节的安全性
5.RSA 密钥交换有一个很大的问题：没有前向安全性Forward Secrecy。这意味着攻J者可以把监听到的加密流量先存起来，后续一旦拿到了私钥，之前所有流量都可以成功解密
2实现方式
目前大部分 HTTPS 流量用的都是 ECDHE 密钥交换。ECDHE 是使用椭圆曲线（ECC）的 DH（Diffie-
Hellman）算法
?
前图中的 Server DH Parameter 是用证书私钥签名的，客户端使用证书公钥就可以验证服务端合法性。相比 RSA 密钥交换，DH 由传递 Premaster Scret 变成了传递 DH 算法所需的 Parameter，然后双方各自算出 Premaster Secret
对于这种情况，由于 Premaster Secret 无需交换，中间人就算有私钥也无法获得 Premaster Secret 和 Master Secret。当然，使用 ECDHE 后，虽然中间人拿到私钥也无法解密之前的流量，但可以实施 MITM 攻J来解密之后的流量，所以私钥还是要保管好。
相比 RSA 既可以用于密钥交换，又可以用于数字签名；ECC 这边就分得比较清楚了：ECDHE 用于密钥交换，ECDSA 用于数字签名
?