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

Posted 2021-12-24 王华_linux

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
d7b5287b412cbf163a94ef80e2ebc2af  fstab
[root@c7-147 /]#mv fstab fstab.bak
[root@c7-147 /]#md5sum fstab.bak 
d7b5287b412cbf163a94ef80e2ebc2af  fstab.bak
[root@c7-147 /]#echo >>fstab.bak 
[root@c7-147 /]#md5sum fstab.bak   #文件的内容变化，hash也发生变化
55515e84e76a213439b8b643efdceb2b  fstab.bak
[root@c7-147 /]#

下载之前的话先记录hash值，然后到别的网站下载对比hash值

[root@c7-147 /]#sha256sum fstab.bak >sha256sum.txt
[root@c7-147 /]#cat sha256sum.txt 
30d967d5475a1736c30130dda1309ab8160746bda18b7e585997ce48f348d237  fstab.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.  中间人攻J

Man-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/TLS

SSL：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 用于数字签名

​