加解密技术
缘起
本周在向组内培训安全编程规范的原则, 其中遇到了不少加解密算法相关的内容, 之前大致都了解过, 但是经常忘记, 因此今天特地写个博客把其中的内容都记录一下.
本片博客内容, 参考了不少这篇文章的内容, 有兴趣可以看原博客, 写的比我好.
对称加密与非对称加密
对称加密使用同一个密钥进行加密和解密, 因此这个密钥是不能公开的, 那么密钥的分发就成了一个大问题, 如何在不受信任的网络之中分发密钥, 成为限制对称加密算法的痛点.
而非对称加密有两个密钥, 一个称之为公钥, 一个称之为私钥. 公钥顾名思义可以在不受信任的网络之中分发, 无论攻击者是否获取了公钥都无法密文.
非对称加密要实现这个能力, 需要有以下特点:
- 公钥和私钥成对出现, 换而言之: 一把公钥有且只有一把私钥, 反之亦然
- 公钥加密的数据有且只能由对应的私钥解密, 反之亦然
非对称加密的传输过程
- 接收方(解密者, 持有私钥) 生成一个密钥, 接收方将公钥广播给发送方(加密者, 持有公钥)
- 发送方将明文字符串安装某种字符串编码格式变成字节流
- 发送方使用公钥对明文数据加密, 再将密文发送给接收方
- 接收方获得密文, 并使用私钥进行解密, 获得明文字节流
- 接收方按照字符串编码格式加字节流解码为明文字符串
整个步骤如下图所示(步骤一一对应):
已知在网络公开的数据有两种: 公钥和密文, 由于非对称算法的特性, 公钥无法对密文进行解密, 这样就保证了数据传输的安全性.
数字签名
签名, 顾名思义就是告诉别人, 这就是我. 在刚才非对称加密传输的例子是公钥持有者发送数据给私钥持有者, 如果反过来, 私钥持有者将数据加密之后发送给公钥持有者, 公钥持有者使用公钥解密数据, 这里由于公钥和数据都是公开的, 那么明文数据是什么已经不重要了, 重要的是这个文件就是私钥持有者加密的, 这个就是数字签名.
它通过非对称加密的原理, 由公钥来验证私钥持有者的身份, 防止密文内容被串改.
当然公钥的安全性是先验的, 也就是说验证者必须知道自己公钥是什么, 而且公钥内容不能被攻击者篡改, 不然给了假的公钥和假的密文, 就往验证者系统注入一个受信内容.
非对称加密算法的缺点
非对称加密算法的执行效率比对称加密算法慢了2-3个数量级, 如果用非对称加密算法去加密数据性能不能接受, 因此在实际上, 这两者一般结合起来一起使用.
对称加密算法的缺点就是无法安全的传输密钥, 那么就由非对称加密算法传输密钥就好了:
- 接收方(持有非对称算法的私钥, 解密者)通过公钥机制生成一对密钥，一个公钥，一个私钥, 并发送给发送方(持有对称算法的密钥和非对称算法的公钥, 加密者)
- 发送方将明文字符串安装某种字符串编码格式变成字节流
- 发送方使用非对称算法公钥对对称算法的密钥加密, 获得加密后的对称密钥
- 发送方使用对称加密的密钥对字节流进行加密
- 发送方将3和4步骤的数据集编码之后发送给接收方
- 接收方拆分掉这两部分数据: 加密后的对称密钥 和 密文
- 接收方用私钥进行解密得到对称算法的密钥。
- 接收方再在用对称加密的密钥对原始的密文进行解密
- 接收方按照字符串编码格式加字节流解码为明文字符串
整个步骤如下图所示(步骤一一对应):
这个图中, 发送者和发送者只有两次交互, 这应该只是为了画图方便, 实际场景之中, 没必要将密钥和密文一起发送, 密文的传输应该就在其中握手过程完成.
常见的对称和非对称加密算法
对称加密最常见的是AES和DES, 但是DES是一种弱加密算法, 不推荐使用
不对称加密常见的有RSA/DSA/SHA256
秘钥的长度最低为:
AES: 128位
RSA: 2048位
DSA: 1024位
SHA: 256位
非对称加密的数学原理
直接丟一个B站的视频, 李永乐老师对RSA算法讲解的非常通熟易懂, 一定要看一遍.
HTTPS认证过程
TBD