对称加密与非对称加密

对称加密:客户端服务器双方统一一个密钥,每次发送数据时都使用该密钥进行加密解密,对称加密由于没有任何的身份标识验证,一开始发送密钥很容易被截胡从而伪装客户端向服务器进行请求

非对称加密:非对称加密主要是通过每个客户端以及每个服务器都存在一对私钥和公钥,私钥只能由当前客户端/服务器单独持有,而公钥则是公开的

而使用非对称加密则存在以下几种方式:

  • 只有一方使用非对称加密

  1. 首先客户端向服务器发送一个加密请求
  2. 服务端收到加密请求后会将自己的公钥发送给客户端
  3. 客户端收到服务器的公钥后,对服务器发送数据时会使用公钥对数据进行加密再传送
  4. 服务器收到客户端的数据后会使用自己的私钥对信息进行解密从而获取数据
  5. 服务端发送数据时则只能使用明文进行传输

显然,这种方式对于服务端传输给客户端的数据没有保障,可能导致消息被截胡更改等风险

  • 双方都使用非对称加密

  1. 首先客户端会向服务器发送一个加密请求
  2. 服务端收到加密请求后会将自己的公钥发送给客户端
  3. 客户端收到服务器的公钥后,会将自己的公钥发送给服务器
  4. 服务器收到公钥后,双方发送数据时都会使用对方的公钥对数据进行加密再发送
  5. 而接收方收到加密数据后会使用自己的私钥对数据解密再获取

通过上述的步骤即可解决双方发送数据存在的不安全问题,保障了数据传输的安全性,但同时这种方式存在一些新的问题:

  1. 双方在第一次传输公钥时可能存在公钥被窃取的风险,从而伪装成发送方
  2. 非对称加密非常耗时,效率非常低下
  • 使用对称加密+非对称加密

  1. 首先客户端会向服务端发送一个加密请求
  2. 服务端收到加密请求后会将自己的公钥发送给客户端
  3. 客户端收到服务端的公钥后,客户端生成一个对称密钥,再使用服务端胡公钥加密一起发送给服务端
  4. 服务端收到密钥和公钥后使用自己的私钥解密从而得到密钥
  5. 当前密钥只存在服务端和客户端,双方即可通过这个密钥进行数据传输

HTTPS就是采用的这种方式

通过上述的步骤即解决了双方都使用非对称加密导致效率低的问题,但还存在双方在第一次传输时不能识别对方的身份,导致公钥的泄露,从而伪装成发送方进行数据传输

这时候我们就需要引出数字证书的概念

网站在使用HTTPS前,需要向“CA机构”申请颁发一份数字证书,数字证书里有证书持有者、证书持有者的公钥等信息,服务器把证书传输给客户端,客户端从证书里取公钥就行了,证书就如身份证一样,可以证明“该公钥对应该服务器”。

  • 对称加密+非对称加密+数字证书

  1. 首先客户端会向服务端发送一个加密请求
  2. 服务端收到加密请求后,会携带自己的公钥以及相关信息发送给CA认证并生成数字证书
    1. CA也同样存在一对公钥和私钥
    2. CA在收到服务端消息后使用摘要算法对服务端信息(公钥)进行hash,再使用CA的私钥对信息加密,生成签名
    3. CA将服务端公钥+信息+数字签名生成数字证书返回给服务端
  3. 服务端收到CA生成的数字证书后发送给客户端
  4. 客户端收到数字证书后会使用CA的公钥对数字签名进行解密得到摘要内容,再使用对应的摘要算法将服务端信息(公钥)hash,对比hash后的数据与摘要内容是否相同,以此来判断数据是否被篡改
  5. 后续客户端生成密钥使用服务端的公钥加密发送给服务端,双方即可得到相同的密钥,从而进行后续的数据传输

摘要算法:对数据进行散列,哈希等处理,且处理后不可还原数据

该方式主要通过一下几点保证数据传输的安全性:

  1. CA是一个认证且唯一不可更改的机构,篡改者无法冒充CA机构或者修改CA信息
  2. 篡改者无法拿到CA的私钥从而保证了数字签名的正确性
  3. 通过摘要算法的不可逆性比较摘要内容是否被修改
  4. 可通过比对信息进一步验证对方的身份
  • 16
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值