加密

小结

• 非对称加密是一种加密和解密使用 不同密钥 的加密算法
• 哈希加密是不可逆的
• https / 中间人攻击 / 证书

概述

为什么需要加密

• 数据即使有安全措施, 能在一定程度防止被非法获取, 但依然有机会会被有心人非法获取, 给敏感数据加密可以一定程度上保护敏感数据
• 数据需要在互联网链路中传输, 传输过程也不可避免地被截获, 明文传输的话就相当于裸奔了

加密会不会被破解

任务加密算法都有办法破解, 只是差的算法破解成本很低, 好的算法破解成本很高

基本术语

明文 (plaintext)

加密前的原始数据

密文 (ciphertext)

密文是通过密码运算后得到的结果, 一般是一个字符串

密钥 (key)

密钥是一种参数, 它是在使用密码算法过程中输入的参数

加密算法

加密算法一般分成三种类型, 对称加密, 非对称加密和哈希加密

非对称加密个人觉得是个非常有意思的加密算法, 虽然我也看不懂原理

对称加密

概念

加密和解密使用 相同密钥 的加密算法

实例: 凯撒密码 / 摩尔斯电码

凯撒密码
加密时, 将字母用右移三位的字母来表示, 解密时将字母左移三位既可
明文字母表：ABCDEFGHIJKLMNOPQRSTUVWXYZ
密文字母表：DEFGHIJKLMNOPQRSTUVWXYZABC

特点

明文通过加密算法和密钥得到密文, 密文也可通过解密算法和 同一个密钥 得到明文

使用

发送方

用密钥和加密算法将密钥加密得到密文

接收方

用 同一个密钥 和解密算法解密得到明文

优缺点

优点

加密 / 解密时间短

缺点

无法保证密钥的安全性, 密钥若在传输过程中被截获, 则无异于明文传输

适用场景

由于 加密/解密效率高, 适合大数据量的加密, 例如传输过程中的数据加密

常见算法

• DES (Data Encryption Standard)
• 3DES (Triple DES), 基于DES, 对明文用三个不同的密钥进行三次加密
• AES (Advanced Encryption Standard)

非对称加密

概念

加密和解密使用 不同密钥 的加密算法

加密和解密用的是不同的密钥, 这个正是非对称加密的奇妙之处

实例: https

本文稍后再详细讲讲 https

特点

加密和解密使用的密钥不一样, 发送方和接收方使用不同的密钥进行加密解密

不同的密钥一个叫公钥, 另一个叫私钥, 公钥和私钥是成对存在的, 已知公钥, 可以推出私钥; 已知私钥可以退出公钥; 重点就在这个推导过程异常艰难

原理

将一个非常复杂的数学问题转化成为解密的必要条件

使用

发送方

• 用私钥将明文加密成密文 (用私钥加密的密文, 只能用公钥解密)
• 用私钥将密文解密成明文

接收方

• 用公钥将密文解密成明文 (用公钥加密的密文, 只能用私钥解密)
• 用公钥将明文加密成密文

接收方完全不需要知道私钥, 故私钥不需要传输给接收方, 私钥泄露的可能性大大降低
接收方用公钥加密后的数据, 只能持有私钥的人能解开, 所以公钥公开在互联网上是完全可以的

优缺点

优点

公钥可公开, 私钥不需要传输给接收方, 安全性高

缺点

加密 / 解密 效率低

适用场景

由于加密 / 解密 效率低, 只适合少量数据的加密

常见算法

• RSA
• ECC

哈希加密 (hash)

概念

通过特定的规则, 将明文转换成 固定长度 的密文

实例: f(x) = x % 10

对称加密和对称加密中, 明文和密文是一一对应的关系, 已知明文可以推导出密文, 已知密文可以推导出明文, 但是哈希加密最大的特点就是一个明文对应一个密文, 但是!!但是一个密文可以对应多个明文, 这就意味着哈希加密是不可逆的, 只能由明文推导出密文, 不能由密文推导出明文(因为一个密文对应着多个明文), 读者可以对着实例 f(x) = x % 10 验证下
造成哈希加密不可逆原因也非常简单, 我们回顾下哈希加密的概念, 固定长度 这四个字非常关键, 固定长度意味着密文的组合个数有限, 而明文很明显是有无限个的, 明文无限而密文有限, 这就意味着明文和密文不可能是一一对应的关系, 只能是一个明文对应一个密文, 一个密文对应多个密文
程序中常提到的哈希值, 其实也就是哈希算法运算得到的结果

特点

不可逆

可由明文推导出密文, 由密文无法推导出明文

冲突

一个明文只对应一个密文, 而一个密文可对应多个明文

原理

简单来说是将无限的集合对应到有限的集合去, 好的哈希算法是尽量避免冲突

使用

发送方

用密钥将明文加密成密文

接收方

接收方由于无法解密密文, 一般直接存储密文

优缺点

优点

加密效率高

缺点

无法通过密文得到明文(既是缺点也是优点, 连自己都不知道明文, 更别指望不法分子得到明文了)

适用场景

用户密码的加密

由于哈希加密的不可逆, 非常适合用来加密用户的密码, 一方面原网站不必知道用户密码的明文, 另一方面即使被不法分子拖库, 要得到用户密码的明文还得折腾

校验文件是否被篡改

我们从网上下载软件, 文档等, 有时候需要校验原文件是否被不法分子篡改过(最常见的是软件会被不法分子植入木马等, 然后发布到各大论坛,网盘等), 原网会提供 md5 等哈希值, 供用户校验

当不法分子篡改过软件, 文档后, 哈希值自然发生改变

这也是我们只推荐在官网上下载软件的原因, 若不是在官网下载的, 也一定要校验哈希值, 哈希值官网上会写明 (既然都要去官网上查哈希值了, 为啥不直接在官网上下载呢…), 当然好像很多厂商都没有提供哈希值, 对这方面不太重视

常见算法

MD5

已经被破解, 不建议使用

SHA

注意: base64 / urlencode / urldecode 是一种编码算法, 并不是加密算法, 不能起到保护数据的作用

破解与防破解

正所谓知己知己百战百胜, 要想防破解, 首先得了解破解有哪些手段, 才能对症下药

前提条件

破解密码的前提是不法分子已经拿到了密文

通用方法

暴力破解

一个个试, 永不过时的暴力破解

字典

常用字母 / 数字 / 符号的组合

所以密码还是不要太简单了, 长度长一点最好

撞库 (社工库)

利用其它网站泄露出来的用户名和密码, 用这些成对的用户名及密码去试其它网站, 主要用以破解网站密码

所以同一个密码不要在不同的网站里面使用, 一旦某一个网站被攻破, 其它网站就很容易被撞库

对称加密

难点

破解对称加密的难点主要在猜测算法及猜测密钥

破解思路

获取传输中的密钥

对称加密需要发送方接收方沟通好密钥, 沟通密钥是比较脆弱的一个环节, 趁他们沟通密钥的网络传输上获取密钥是比较省事的一个方法

防破解思路

• 密钥需要加密再进行传输, 最好使用非对称加密算法对密钥进行加密
• 同一个密钥不要复用

非对称加密

破解思路

由于公钥是公开的, 难点就在于猜私钥, 而对于私钥目前没有特别好的破解方法, 基本只有暴力破解了, 暴力破解的成功率非常低

非对称加密的破解难点在于巨大的运算量, 但也不是没有希望, 有些人希望能够通过量子计算机来破解, 但从目前的量子计算机的研究进度来看, 仍然任重而道远

哈希加密

破解方法

彩虹表

一个表格, 存储的是常用的明文及其哈希密文, 通过对比密文找到明文

防破解

加随机盐

一般的彩虹表, 长度有限, 组合有限, 通过加盐来跳出彩虹表的范围;
如果不加盐, 破解了同一个明文, 则所有相同的明文(主要是密码)都被破解了, 就随机盐就不会有这种情况;
而且如果是固定的盐, 被破解出来了几个明文, 盐值很容易就被猜出来, 故应使用随机盐

这里说的盐并不是平时吃的盐, 是指一个字符串, 名称就叫盐

题外话, 现实里多数密码, 保密文档的泄露, 大多不是技术层面上的原因, 而是由于内鬼, 毕竟日防夜防, 家贼难防

https

https 是浏览器端到端的数据加密解密

原理

本质上是 对传输的数据进行对称加密, 关键在于对称加密密钥是通过非对称加密进行加密的

1. 浏览器端向服务器拿公钥, 服务器将公钥发送给浏览器
2. 浏览器端随机生成一个对称加密的密钥key, 用公钥对key进行加密, 传输给服务端, 由于采用的是非对称加密, 所以没有私钥的人无法破解该key
3. 服务端拿到密文后, 用私钥对明文进行解密, 得到对称加密的密钥key
4. 后面服务端和浏览器端就用对称加密进行大量的数据传输了

这里充分应用了 对称加密及非对称加密的优点, 对称加密适合大量数据的加密, 但交换密钥的过程非常脆弱, 但是每次通讯只需要交换一次密钥即可, 适合使用非对称加密, 非常安全, 即使效率较慢, 但交换密钥的次数非常少, 可以接受

中间人攻击

中间人攻击是非常有意思的一种攻击

假设在浏览器端在和服务端通信时, 都由中间人来转发(最简单的实例: 代理服务器), 按照上述的流程来进行加密, 会存在所谓的中间人攻击的漏洞

让我们来看下中间人攻击是如何做的:

• 浏览器端向服务器拿公钥, 服务器将公钥发送给浏览器

在这步里面, 中间人拿到服务器的公钥PA, 但是不发送这个公钥PA给浏览器, 而是发送自己伪造的公钥PB给浏览器, 服务器的公钥PA中间人自己仍然保留

这个时候, 其实浏览器端拿到的并不是服务器的公钥PA, 而是中间人伪造的公钥, 但是浏览器端并不知情

• 浏览器端随机生成一个对称加密的密钥key, 用公钥对key进行加密, 传输给服务端, 由于采用的是非对称加密, 所以没有私钥的人无法破解该key

浏览器端使用 公钥PA 对 密钥key 进行加密, 发送, 被中间人接收到, 注意, 这个时候, 中间人可以通过自己的密钥对该密文进行解密得到明文! (因为公钥是中间人的), 中间人再用公钥PB对密钥明文进行加密, 发送给服务器端, 服务器用自己的密钥也能成功解密, 得到密钥key 明文. 之后浏览器端和服务器端用对称加密进行通信, 而中间人均能够用密钥key进行解密, 双方的加密通信如同明文般被中间人读取.

如此操作以后, 中间人便神不知鬼不觉地欺骗了 浏览器端和服务器端, 让他们均以为安全, 殊不知在中间人面前如同裸奔一样

由于存在中间人攻击的问题, 引出了证书的解决方案

解决方案

我们回顾下中间人攻击的过程, 弱点在浏览器端不能分辨各个服务器(域名)的公钥, 从而被中间人替换公钥, 如果浏览器端能够分辨中间人的公钥并不是服务器端(域名)对应的公钥, 则中间人攻击便无法实现

于是引入了 证书 的概念

其他术语

证书 (CA)

主要作用是 让客户端相信拿到的服务端的公钥真正属于 服务端的，而不是其他中间人伪造的

而在 CA 是如何才能让认证这个公钥是 服务端 的呢？

这里需要另外一个概念：数字证书。

普通证书产生的过程就是：将个人提交的信息进行第三方具有权威性部门的认证，然后第三方权威部门确认个人信息合法无误后在自己的系统中登记，再把认证证书盖章签名给到个人手上，然后个人就可以用证书从事各类证明活动。现实世界中的做法是在个人提交的信息上盖章，例如4，6级的证书认证。假设你的成绩申请无误而合法，教育局就会将你的成绩记录，然后给你一张盖过章的证书。

数字证书同理。不过，与现实不一样，在互联网上完成一个完整的验证过程，需要兼顾到很多过程中的纰漏。

简易的https流程

• 客户端向服务端发起安全连接的https请求
• 服务端返回证书, 客户端验证证书, 得到服务端的公钥
• 客户端生成随机的对称加密的密钥, 并使用公钥对对称加密的密钥进行加密, 将密钥密文传输给服务端
• 服务端用私钥解密得到对称加密的密钥, 至此以后, 服务端和客户端通过对称加密进行数据传输

参考

也许，这样理解HTTPS更容易