加解密方式演进简读

加解密方式简读

1.对称加密

对称加密算法指“加密和解密使用相同密钥”的加密算法，又叫传统加密算法

• 对称加密的优点：
  计算量小、加密速度快、加密效率高
• 对称加密的缺点：
  秘钥需要传递，难以确保秘钥安全性
  缺乏签名功能，即不能核对发信人身份

为了解决密钥在传输过程中的恶意截获的危险，保护好密钥。产生了公私钥，即非对称加密

2.非对称加密

• 公钥和私钥是一个算法中两个不同又内在相关联的参数集合，同时生成，但可以独立使用。
• 公钥加密的数据只有对应的私钥才可以解密（公钥加密后公钥也不能解密）
• 私钥加密的数据也只有对应的公钥才可以解密。

举个github的例子，git支持https和git两种传输协议，github分享链接时会有两种协议可选：

• 若git使用https协议，每次pull, push均提示要输入密码
• 使用git协议，然后使用ssh密钥对认证，即可实现免密。

假如你使用git协议从自己的git仓库中拉取代码

• 首先需要在本地生成一对公私钥，私钥是本地保存的
• 公钥你要是配置在git服务中的。在github上配置公钥
• 把git的 remote url 修改为git协议（以上两个步骤初次设置过以后，以后使用都不需要再次设置，此步骤视以后项目的remote url而定，如果以后其他项目的协议为https则需要此步骤。使用命令 git remote -v （需在事先clone的项目目录中执行）查看你当前的 remote url）
• 使用命令 git remote -v 查看一下，url是否已经变成了ssh地址。
  然后就可以愉快的使用git fetch, git pull , git push，不用再输入密码
  具体步骤见: 配置git使用ssh密钥.

公钥是公开的，任何人都可以获得到。
同样的，双方也可以实现双向通信加密，就是各自生成一对
举个例子来看一下：

• A 根据非对称加密算法生成自己的公私钥对（公钥A，私钥A）；
• B 也根据非对称加密算法生成自己的公私钥对（公钥B，私钥B）；
• A 和 B 可以公开的交换自己的公钥（私钥不需要发送，各自保存好即可）；
• A发送信息给B时， 使用 B 的公钥 公钥B加密信息，发送给 B；
• B 接收到消息后，使用自己保存的私钥B 解密就可以看到消息内容（这条消息即使被他人获得后也是不能解密的）；
  同样，B 要发消息给A 时，使用 A 的公钥A 加密发出；
• A 收到消息后使用自己的私钥A 解密，这样就实现了双方加密的通信。

实际使用中又出问题了，那就是 A收到消息后如何确认发信人是B 而不是C或者D？其实也很简单，只要发消息前多进行一次使用自己的私钥加密就可以了，这次使用自己私钥加密信息的步骤就叫做签名。

3.签名

公钥一般用来加密，私钥用来签名。
举个例子：

• A 先使用自己的私钥 A 对消息进行一遍加密（习惯性称作签名），再使用 B 的公钥 B 加密信息，然后将加密结果发送给 B。
• B 接收到消息后，使用自己保存的私钥 B 解密，然后使用 A 的公钥 A 再解密一遍，如果能解密成功，就可以确保这条消息不是伪造的。
• 同样，B 要发消息给A时先使用自己的私钥B 对消息进行一遍加密（习惯性称作签名），再使用A 的公钥A 加密后发出。
• A 收到消息后使用自己的私钥 A 解密，然后使用 B 的公钥 B 再解密一遍，这样就实现了双方互相确认身份的加密通信。

由于非对称加密是复杂且耗时的，而且需要加密的内容越长就越耗时。在实际使用中一般经过摘要算法得到一串哈希值，然后使用私钥对哈希值进行加密。习惯性将这样对摘要使用私钥加密生成的文件叫做签名文件

4.哈希值算法

哈希值算法主要是为了保证数据传输的完整性，防止被恶意篡改。

生成摘要的哈希算法有如下特点：

• 可以将任意长度的信息与一串固定长度的字符串建立对应关系，即哈希值定长
• 哈希值算法将任意长度映射为有限长度，难免有碰撞（即，两个不同信息算出的摘要相同）。好的哈希值算法就是能够尽量减少碰撞的几率
• 原始信息的任何一点修改都会导致计算出的哈希值的变化，从而可以用哈希值来确保消息体的完整性。
• 哈希值算法是单向的，即只能从原信息计算出哈希值，不能由哈希值回算得到原信息。

演化出了目前实际使用的签名、加密过程：

• A 先使用哈希算法将要发送的消息计算出摘要，再自己的私钥A 对摘要进行签名得到签名文件，然后将原始消息和签名文件打包到一起，使用 B 的公钥 B 加密信息，发送给 B。
• B 接收到消息后，使用自己保存的私钥B 解密，得到原始消息和一个签名文件。使用哈希算法对原始消息计算得到一个哈希值，再使用 A 的公钥 A 对签名文件进行解密，得到消息的哈希值，将这两个哈希值进行对比，如果一致就可以认为这条消息是 A发送的且未经过篡改。

5.公钥与证书授权中心 CA

为了防止第三方轻易的发布自己的公钥宣称这是 A的公钥来欺骗,这就需要一个结构来保证了，这个机构把 A 提供的公钥和A 的相关信息放在一起组合成一份证书，这样你从这个机构获取证书，就可以得到有权威机构背书的公钥与 A 的对应关系。

CA 证书授权（CertificateAuthority）中心是数字证书发行的唯一机构。

CA 中心又称 CA 机构，即证书授权中心（Certificate Authority），或称证书授权机构，作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。CA 中心为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。CA 机构的数字签名使得攻击者不能伪造和篡改证书。在 SET 交易中，CA 不仅对持卡人、商户发放证书，还要对获款的银行、网关发放证书。它负责产生、分配并管理所有参与网上交易的个体所需的数字证书，因此是安全电子交易的核心环节。

CA 证书是逐级保证安全的，最终的根证书内置在操作系统中。由操作系统来保证，这部分下文中会进行介绍。

对称加密与非对称加密的联合使用
由于非对称加密是耗时的，如果在每一次 HTTPS 的数据传输中都使用非对称加密是不合适的。实际上的做法是在第一次建立 HTTPS 连接时使用一次非对称加密传递对称加密的秘钥，然后就使用对称加密来保证接下来的通信过程。

• HTTPS 的通信过程如下：

1. 浏览器发出 HTTPS 请求。
2. 服务器返回本网站的证书。
3. 浏览器基于内置在操作系统中的CA证书链对网站证书的有效性进行校验。校验通过后使用证书中的公钥加密一份对称加密的秘钥信息，发送给服务端。
4. 服务端收到信息后使用自己的私钥解密信息，得到浏览器提供的对称加密秘钥信息。之后的通信过程就使用这个对称加密秘钥来保护。