RSA 加密解密和签名验证

分析数字证书的签名和验证以及 RSA 非对称加密解密的时候,又想到了 SSH 中登陆流程,服务器是如何在 authorized_keys 找到当前登陆客户端与之匹配的公钥呢??

1. RSA 非对称加密解密

  1. 公钥加密,私钥解密:
    记忆口诀: 加密的数据,只希望自己能解密,那么公钥加密,私钥解密。
  2. 因为非对称加密的性能比对称加密的性能低,所以,在加密通信中,往往使用的是对称加密,而对称加密使用的密钥是通过非对称加密来传输的。
    • 客户端生成一个随机密钥串,然后通过服务端的公钥加密发送给服务端。
    • 服务端使用私钥,解密获取随机密钥串。
    • 服务端和客户端使用随机密钥串的对称加密来进行通信。

2. 签名和验证

私钥加密(生成签名),公钥验证(验证签名):
记忆口诀: 自己提供了一段数据,希望别人能相信一定是自己提供的,那么私钥加密,公钥就可以验证。

签名和验证,目的是为了证明数据确实是私钥持有人发出来的。
生成签名: 直接对消息进行加密,此时不是为了对消息保密,而是为了签名。
验证签名: 验证者通过公钥解密消息,如果和原消息一直,则认为签名成功。

通常,由于消息可能会很长,所以往往是对消息做一个散列值,然后再在签名操作,提高效率。

3. HTTPS 建立流程

  1. 客户端发送一条 ClientHello 给服务端,包含:
    • 支持的协议版本,例如 TLS 1.0
    • 客户端支持的对称/非对称加密算法,压缩方式
    • 客户端生成的随机数1
  2. 服务端收到消息后,回一条 ServerHello :
    • 确定使用的对称/非对称加密算法,压缩方式
    • 服务端的 SSL 证书,证书包含的内容(证书的发布机构,证书的有效期,公钥,证书的持有者,签名)
    • 服务端生成的随机数2
  3. 客户端收到后服务端的消息后:
    • 校验证书
    • 生成一个随机数3。通过 3 个随机数计算出最终的会话密钥,并用服务端的公钥加密,发送给服务端,告诉服务端,后续将会采用会话密钥使用协定的对称加密算法发送消息。
  4. 服务端收到消息后,解密密钥。服务端确认握手结束,下一步开始使用协商的对称加密算法 + 会话密钥通信。

校验证书,是为了防止中间人攻击,保证服务端的证书是可信的。

3.1. 数字证书的验证

3.1.1. 2个概念:

指纹:数字证书的主题的 HASH 值。
签名:使用 CA (证书管理机构) 的私钥,对指纹做的签名(加密)。

浏览器获取到证书后,取出证书中的签名部分,用自身根证书中对应的证书的公钥进行解密,如果解密成功,再生成HASH值和获取到的证书中的指纹来比较是否一致。

Just for my love !!