Android 深入Http（2）加密与编码

最新推荐文章于 2024-04-06 06:42:48 发布

RikkaTheWorld

最新推荐文章于 2024-04-06 06:42:48 发布

阅读量326

点赞数

分类专栏：计算机网络

本文链接：https://blog.csdn.net/rikkatheworld/article/details/94130154

版权

计算机网络专栏收录该内容

10 篇文章 0 订阅

订阅专栏

上次学习了Http的工作原理和机制，现在学习更加细节的，用在传输过程的一个必要的知识。
那就是加密解密、编码解码、hash等。

加密、编码

网络上分为两种加密方式。
分别是对称加密和非对称加密。
下面我们来对这两种加密进行概念上的学习。

但是首先得知道，加密解密的过程，会出现的几个概念或者对象。

原数据（又称明文）
就是要发送的数据的最初的状态
密文
被加密后数据就是密文
发送方
就是持有原数据的一方，他们会对原数据加密变成密文，然后发送该密文
接收方
接受传过来的数据的一方，他们会对密文解密，得到可读的原数据
盗窃方
恶意的嗨客会在网络上截取这些传输的密文，他们可能会通过暴力枚举的手段进行解密。网络安全、加密解密就是为了防止这些嗨客得到密文之后可以轻易的破解。
从理论来说，嗨客是不可能拿不到我们的密文的，因为网络传输时数据要经过很多个节点，我们是不能保证每个节点都是100000%安全的，也就是说，可能存在必经的节点是一个嗨客的节点，那么嗨客就能拿到这个密文。
密钥
密码钥匙，用来加密和解密的工具，他可以是一个算法，可以是一个映射表，总之通过它，原数据能变成密文，密文能变成原数据
加密算法
和密钥配合使用，可以认为 （明文 + 密钥） + 加密算法 ----> 密文
一般来说，加密算法是公开的，但是密钥都是保密的。
因为都是用同样加密算法加密和解密，所以解密的时候一定会产生数据溢出，
比如一个 RIKKA 通过加密算法变成了 aohfohioqyrfopq… （明文通过算返后边的很长）
然后解密的时候又用同样的算法变成了 aSIHjfophagepoa…（更长了，数据都溢出了）
再通过密钥就变成了 RIKKA。所以数据溢出是很正常的。

对称加密

在这里插入图片描述
这个图就很直观，很明了的表现出了对称加密。它有如下的特点：

发送发通过加密算法配合密钥对原数据加密得到密文，接收方通过加密算法和相同的密钥来解密得到明文。
加密算法和解密算法应该是互逆的
双发从一开始就持有了相同的密钥

这么说，从一开始，发送/接收双方就已经有同样的密钥了。

加密算法的原理：

发送方将明文（原始数据）和 加密密钥 一起经过特殊加密算法处理后，使其变成复杂无意义的 加密密文
发送出去。
收信方收到密文后，使用加密用过的密钥及相同算法的逆算法对密文进行解密，才能使其恢复成可读明文。

可以对二进制数据（比如图片、视频）
经典算法：
DES（密钥短被弃用了）
AES （密钥很长很顶）速度快，效率高
IDEA
3DES（三重DES，听起来就很慢和重 = =，但是应该更难破解了）

至于具体的算法处理网上有许多文章。

非对称加密

原理：A使用公钥和 加密算法 对数据加密得到密文发送给B，B使用私钥和 相同的加密算法 对数据加密得到明文。

那这里有一个问题了：这样看来私钥能解公钥加密的数据，那这样，非对称加密和对称加密不是没什么不同吗？？？？

这个问题的答案就是非对称加密和对称加密的本质的区分：
答案如下：

A 有自己的公钥和私钥，假设叫 A公钥和 A私钥，它们互逆，能相互解开对方加密的数据。
B 也有自己的公钥和私钥，叫 B公钥和 B私钥，同样也是互逆， B公钥能解开B私钥加密后的数据，反过来也是
对称加密中公钥和私钥虽然互逆，但是A B两端也只用这一对唯一的密钥。
非对称加密中，A B都有了属于自己的一对公钥密钥
A使用了B（对方）的公钥对数据进行了加密，这也是为什么 B能够使用自己的私钥对密文进行解密

这就是非对称加密的本质。
那么实际情况时，A是怎么知道B的公钥呢？
答案是：在双方沟通开始前，双方各自就给对方发公钥，然后就能得到对方的公钥了。
就是嗨客拿到了密文还有公钥，他也不能解出来，因为密文是要用私钥去解的。

所以公钥为什么叫公钥，就是人人都可以获取的。
公钥也可以解开由私钥加密的密文。但是他们不能对换的。

非对称加密用途：数字签名

数字签名就是利用公钥也能解私钥的特点来做的

数字签名的原理是：
拿自己的私钥去对原数据进行加密，别人如果能通过我的公钥对数据还原，这就说明这份数据的确是我自己造的。这就是签名。
别人因为没有自己的私钥，所以伪造不出同样的签名数据。

有了数字签名与验证，那么在平时的加密过程中：A可以向B发送一个原数据+一个数字签名，B收到之后会看到了原数据。那么他会验证是不是A写的，如果他拿A的公钥去解开了数字签名，那么就说明的确是A这个端发的原数据，而不是别人伪造了一份原数据。

↑ 这个做法在后面的HTTPS的TLS机制中有用到，通过验证数字签名，来判断对方是不是我想要去信任的一端。

当然了，上面的例子中也可以把原数据加密一下，那这样带的就是密文＋签名数据了。

数字签名可以使非对称加密更加安全

前面说过，嗨客是可以在AB数据传输中的路上获取密文的，如果他截取了密文，然后又拿到了B的公钥，那么，他可以伪造一份原数据：“你给我转100到xxx账户”，然后拿B的公钥去加密，给B，B收到后因为可以用自己的私钥给解开，所以他会觉得这份数据就是A发的，然后他就转钱了。

这绝对是很不安全的。
通过数字签名的学习我们可以做到下面几步来让数据传输更加安全：

A 使用B公钥对原数据加密得到密文，用A私钥对自己信息加密得到签名。
A发送密文＋签名给B。
B通过 B的私钥来解密文，再用A的公钥来解签名
验证都Ok，好，保证这份数据是A传给B的。因为嗨客没有A的私钥，所以嗨客不能构造A的签名。

经典算法：
RSA：用来签名、原文加密都行。
DSA：专门设计用来签名。（签名更加快）

Base64

原理：将二进制数据（非文本数据）转换成由64个字符组成的字符串的编码算法。
64个字符是0-9 a-z A-Z + / 有个专门的码表（映射表）

比如 M的ASCII是77，对应的二进制是 01001101。
然后自己规定，每6位截取一下，那么就能切成 010011 + 01，其中前半部分换成10进制是19，在码表中对应T，后半部分01换成十进制是1，在码表中对应B。
那么M被Base64转换之后就变成了 TB。
其中最多只能规定6位截取一下，因为码表只有64个字符，如果超出6位，那么多出来的码表就没有了。

当然了，还有Base58。
所以Base64的本质将二进制数据转换成字符串。（比如图片、视频）
所以它的用途是：可以放在URL中传输、可以保存到文本文件、可以进行文本传输。

但是Base64用来加密，肯定是不安全的，Base64码表任何人都知道，直接转过来就行了。
而且Base64完全不高效，都把数据变得更长了。相反它很低效，能不用就不用。

URL encoding是Base64的变种

URL可能识别不了中文，所以它会将中文转换成Base64，使用%来编码

压缩与解压缩

压缩的概念是将数据换一种方式来存储，以减小存储空间
解压缩则是将压缩后的数据还原成原来的数据
原则上压缩不算编码。

常见的压缩算法有：DEFLATE (有没有像Android的INFLATE)、JPEG、MP3
DEFLATE：zip的压缩归档使用的算法就是DEFLATE
JPEG是对JGP的图片进行压缩，MP3则是对音频进行一个压缩。

序列化

序列化的概念是：
把数据对象转换成字节序列的过程，主要用于存储和网络传输。

反序列化就是倒过来，成为内存中的对象。
序列化和反序列化并不算编码。

Hash

Hash大家都很熟：把任意数据转换成指定范围的数据。

算法有：MD5、SHA1、SHA256

实际用途：
数据完整性验证：根据传输前后的数据哈希值进行比对来验证传输过程是否出现数据丢失
快速查找：hashCode()（要同时重写equals和hashCode）、HashSet、HashTable、HashMap
隐私安全：因为Hash不可逆，所以可以用来将密码什么的用哈希值来保存。（加盐：对原数据加上一个特定的数据再进行哈希，用来预防彩虹表破解）

Hash也不算编码，因为其不能逆向转换。所以更说不上加密。

Hash在非对称加密的应用：
因为签名数据一般特别大，所以用加密算法和私钥加密后会变得更大，所以很占带宽，一般都会先对签名数据进行Hash，变成很小的数据，再进行加密。就会比原来的小很多（接收方来验证签名的时候也是验证签名的Hash值，这样的话也更加快捷）