对称式加密
加密和解密都使用同一把密钥
网络上传输的数据是加密的，第三方窃听者甚至无法破解
缺点在于需要交换密钥
解决密钥交换的方式是密钥交换算法和非对称加密算法
密钥交换算法
前提：单向散列函数，给出F（x）和F，无法推出x
假设有三个人，Alice，Bob和Hack（第三方中间人），Hack现在想窃听Alice和Bob的聊天信息
假设Alice和Bob想出两个数字A和B想出两个数字A和B，且确定用G作为生成元（三方都知道）
Alice使用A和G生成AG
Bob使用B和G生成BG
网络数据交换，Alice获得BG，Bob获得AG，Hack获得AG和BG（此时Hack知晓AG，BG和G，但是由于单向散列函数的特性无法推出A和B）
Alice使用BG和A通过运算手段获得ABG
Bob使用AG和B通过运算手段获得ABG
这样Alice和Bob得到了他们共有的限定的数
Hack因为无法确定A或者B所以无法确定ABG
flowchart LR
subgraph 生成元
G
end
subgraph Alice和Bob都知晓
ABG
end
subgraph Alice
A --> G -->|生成| AG -->|给Bob| Bob知道AG和BG和B -->|通过算法使用AG和B生成ABG| ABG
end
subgraph Bob
B --> G -->|生成| BG -->|给Alice| Alice知道BG和AG和A -->|通过算法使用BG和A生成ABG| ABG
end
中间人攻击
对于密钥交换算法，Hack想出了一种方式来破解
不再是窃听，而是直接冒充Alice和Bob的身份进行交流
非对称加密
非对称加密的思路是，将加密密钥和解密密钥分开，公钥用于加密，私钥用于解密
只把我的公钥给对方，对方用我的公钥，到本地用自己的私钥解密
可以这样想，公钥是锁，私钥是钥匙，把锁给别人，钥匙留在自己这里，这样方便理解
常见的RSA算法就是典型的非对称加密算法
实际应用中非对称加密的运算速度要慢于对称性加密，所以在传输大量数据的时候，非对称加密传输的先是对称加密的密钥，然后通过对称加密密钥来传输数据，这样效率更高
sequenceDiagram
Alice->>Bob: 公钥加密{对称加密密钥}之后发送给对方
Bob->>Bob: 解密后获得{对称加密密钥}
Bob->>Alice: 使用对称及加密密钥发送数据
Alice->>Alice: 接收，使用{对称加密密钥}解密
Alice->>Bob: 再次加密数据，发送
Bob-->>Alice: 循环往复
注意，非对称加密也无法防范中间人攻击，比如Hack拦截了Alice的公钥，然后伪装Bob给Alice发信息
数字签名
非对称加密的私钥其实也可以用来加密，然后使用公钥解密，数字签名和非对称加密有点类似只不过完全颠倒
用你的私钥将数据发送出去，这就是数字签名
数字签名的意义在于，验证身份，能解开私钥加密过的数字签名，那么也就确定了你的身份
流程大致是：
-
生成公钥和私钥，公钥发出去
-
你将数据和数字签名（加密后的数据）发出去
-
对方接收数据和数字签名并验证
数字签名同时有着确认完整性的功能，加密的数据其实是全部数据的hash值
这里有个小问题，在使用数字签名认证了身份后，之后的传输数据还需要附带数字签名吗，数字签名的效果是确认发送方的身份，需要密钥解密，我们第一次解密得到的是对称式加密密钥，之后我们用来加密的就是对称式加密了，解不开就说明遭到中间人攻击，所以之后无需数字签名
sequenceDiagram
Alice->>Alice: 生成公钥和私钥
Alice->>Bob: Alice的公钥发给Bob
Alice->>Bob: 将数据和数字签名（加密后的数据）发出去
Bob->>Bob: 接收数字签名，确认身份，解密数据，获得对称式加密密钥
Bob->>Bob: 用对称式加密密钥加密数据
Bob->>Alice: 传输
Alice-->>Bob: 循环往复
假设中间人修改了明文数据，那么解密之后的数字签名与明文不符
如果中间人修改了数字签名，那么解密之后数字签名极可能乱码无法解读
如果中间人同时修改了数字签名和明文数据，那么对方的公钥无法正确解开，哪怕解开了数据返回的时候的数字签名也不是中间人的
数字签名从一定程度上可以认定数据发送方的身份，之所以是一定程度上，是因为公钥的分发过程还是有可能出问题，可能在最开始公钥就被中间人修改了
数字签名是一种用于身份认证的方式，但是最开始的公钥分发就有可能出问题…对于公钥分发，要先确定你的身份是真的，但是数字签名就是用来解决身份认证问题的…陷入死循环了…
我们需要找一个大家都信任的第三方机构，来认证你的身份，如此公钥分发便安全许多
公钥证书
证书其实就是公钥+签名，由第三方受信任的机构(certificate authority,简称CA)颁发
流程如下：
一般来讲浏览器会预先安装几个正规机构的证书，用于确认身份，所以证书的认证还是可信的，所以不要乱装不正规浏览器
现在的网站大多使用的是HTTPS协议，就是在 HTTP 协议和 TCP 协议之间加了一个 SSL/TLS 安全层。在你的浏览器和网站服务器完成 TCP 握手后，SSL 协议层也会进行 SSL 握手交换安全参数，其中就包含该网站的证书，以便浏览器验证站点身份。SSL 安全层验证完成之后，上层的 HTTP 协议内容都会被加密，保证数据的安全传输。
补充
安全技术最多只能保证技术上无问题，但是不代表着完全安全，第三方认证机构也不一定完全安全
HTTPS认证流程
sequenceDiagram
浏览器->>服务器: 发出请求
服务器->>浏览器: 用私钥加密网页后，加上本身的数字签名一起发送
浏览器-->>CA: 浏览器根据CA签证去找CA确定网站信息，如果没有则网页数据无法加密
CA-->>浏览器: 返回网站的证书（公钥+签名）
浏览器-->浏览器: 验证证书是否正常
浏览器->>服务器: 交互信息，循环往复
RSA公钥私钥可否互换
原理上是可行的，但是实际上由于一些生成算法和其他情况，不可行
例如一种情况：公钥就是用私钥生成的，公开私钥=公开公钥和私钥
参考：