android 对称加密和非对称加密 安卓非对称加密

对称加密

• 简介：对称加密算法又称传统加密算法，加密和解密使用同一个密钥。
• 加密解密过程：明文->密钥加密->密文，密文->密钥解密->明文。

• 缺点：对称加密算法是不现实的，互联网中通信的双方大多是临时建立的连接，不可能提前协商好密钥，而且密钥也要进行传输，无法保证密钥本身的安全性。

非对称加密

• 简介：
  非对称加密（asymmetric cryptography），也称为公开密钥加密（Public-key cryptography），是密码学的一种算法，它需要两个密钥，一个是公开密钥，另一个是私有密钥。顾名思义，公钥可以任意对外发布；而私钥必须由用户自行严格秘密保管，绝不透过任何途径向任何人提供，也不会透露给要通信的另一方，即使他被信任。

非对称加密应用场景

一、加密通信（公钥加密-私钥解密）

加密解密过程：明文->公钥加密->密文，密文->私钥解密->明文。

客户端向服务器发送数据是安全的，客户端用服务器的公钥进行加密，只有服务器用自己的私钥才能解密。

二、数字签名

加解密过程：
1.客户端发送信息，并且携带自己的公钥，同时使用私钥对信息明文进行加密，这个密文可以看做该客户端的签名，最终格式大致为：信息明文+公钥+私钥对信息进行加密（签名） 2.服务器使用信息中携带的公钥对签名进行解密，解密结果与信息明文进行比较，如果一致则是本人发送，因为本人才拥有私钥。如果不一致，则说明消息不是该客户端发送的，或者虽然消息是该客户端发送的但已遭到他人篡改。

注1：上面仅仅是对数字签名技术的一个简单描述，很好理解吧~实际应用中的操作略有区别，比如通常是先对明文进行hash，再对hash后结果用私钥进行签名。

通信示例：

1.Alice需要使用具体约定的算法（例如RSA）生成密钥和公钥，密钥自己保留，公钥对外公布。

2.当Alice想要发送消息 Alice已向Bob转账1BTC，请查收。| 我的公钥是：“gh3giPGFN2jgh3sF”。 时，Alice使用自己的私钥对消息进行加密，假设加密后的密文是 SHG356g3T4+dh4fh，现在这个密文可以看作Alice的数字签名。

3.Alice将消息明文和数字签名放到一起并发送到网络中

发送的消息类似这样的形式 Alice已向Bob转账1BTC，请查收。| 我的公钥是：gh3giPGFN2jgh3sF。| 签名：SHG356g3T4+dh4fh

4.网络中的所有人接收到消息后，都可以进行如下操作完成验证：

收到消息 Alice已向Bob转账1BTC，请查收。| 我的公钥是：gh3giPGFN2jgh3sF。| 签名：SHG356g3T4+dh4fh

使用Alice在消息中提供的公钥 gh3giPGFN2jgh3sF对私钥签署的数字签名SHG356g3T4+dh4fh进行解密

将解密结果与消息明文 Alice已向Bob转账1BTC，请查收。| 我的公钥是：gh3giPGFN2jgh3s进行对比

如果一致，说明消息是Alice亲自发送的，因为只有Alice本人拥有Alice的密钥

如果不一致，则说明消息不是Alice发送的，或者虽然消息是Alice发送的但已遭到他人篡改

5.于是，通过4中描述的方法，Bob确认了Alice给他了一笔价值1BTC的转账。

数字签名大致流程

通常会对原数据 hash 以后对 hash 签名，然后附加在原数据的后⾯作为签名。这是为了让数据更⼩。

HTTPS的实现原理

① 证书验证阶段：

1. 浏览器发起 HTTPS 请求；
2. 服务端返回 HTTPS 证书；
3. 客户端验证证书是否合法，如果不合法则提示告警。

② 数据传输阶段：

1. 当证书验证合法后，在本地生成随机数；
2. 通过公钥加密随机数，并把加密后的随机数传输到服务端；
3. 服务端通过私钥对随机数进行解密；
4. 服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输。

HTTPS用的是对称加密还是非对称加密？

大家可能都听说过 HTTPS 协议之所以是安全的是因为 HTTPS 协议会对传输的数据进行加密，而加密过程是使用了非对称加密实现。但其实：HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。

为什么数据传输是用对称加密的？

首先：非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的。
另外：在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密

为什么需要CA机构颁发证书？

防止”中间人“攻击，同时可以为网站提供身份证明。

抓包工具原理

1. 客户端请求建立HTTPS链接，发送客户端支持的加密协议及版本列表等信息给服务器端。
2. Fiddler接受客户端请求并伪装成客户端向WEB服务器发送相同的请求。
3. 服务器收到Fiddler的请求以后，从请求中筛选合适的加密协议。并返回服务器CA证书，证书中包括公钥信息。
4. Fiddler收到服务器的响应后保存服务器证书并自签名一个CA证书，伪装成服务器，把该证书下发给客户端。
5. 客户端验证证书合法性，（Fiddler能否抓取到HTTPS报文关键看这一步）
6. 客户端生产对称密钥，通过证书的公钥加密发送给服务器。
7. Fiddler拦截客户端的请求以后，使用私钥解密该报文，获取对称加密秘钥，并使用服务器证书中带的公钥加密该对称密钥发送给服务器。此时对称密钥已经泄露了，以后可以使用该秘钥界面客户端和服务器端传输的数据。
8. 服务器接收到客户端发送的加密的对称密钥后使用私钥解密，并使用对称密钥加密测试数据传给客户端。
9. Fiddler使用前面获取的对称密钥解密报文。
10. 客户端验证数据无误以后HTTPS连接就建立完成，客户端开始向服务器发送使用对称密钥加密的业务数据
11. Fiddler使用前面获取的对称密钥解密客户端发送的数据并重新加密转发给客户端。

抓包原理总结

HTTPS抓包的原理还是挺简单的，简单来说，就是Fiddler作为中间人代理 ，拿到了 服务器证书公钥 和 HTTPS连接的对称密钥，前提是客户端选择信任并安装Fiddler的CA证书，否则客户端就会“报警”并中止连接。这样看来，HTTPS还是很安全的。