Linux下数据传输安全与加密
概述：两个计算机在互联网上通信时，它们之间发送的信息如果不经过特殊的处理，即加密机制，很容易被其他人给获取到，如果是普通的信息，那倒是无所谓，但是如果涉及到个人的私密信息，那这样岂不是很糟糕，本篇来说一下这个安全和加密机制。
加密算法和协议：
对称加密：数据加密（保密性）（3DES,AES)
公钥加密：身份认证、**交换、数据加密（不常用，比对称加密要慢3个数量级）（RSA,DSA）
单项加密：数据完整性（MD5,SHA）
**交换：RSA、DH（迪菲-赫尔曼）、ECDH（椭圆曲线DH）、ECDHE（临时椭圆曲线DH）
****************************************************************************************************
对称加密：加密和解密使用同一个**
DES：Data Encryption Standard，56bits
3DES：
AES：Advanced (128, 192, 256bits)
Blowfish，Twofish
IDEA，RC6，CAST5
特性：
1、加密、解密使用同一个**，效率高
2、将原始数据分割成固定大小的块，逐个进行加密
缺陷：
1、**过多
2、**分发
3、数据来源无法确认
非对称加密算法：即公钥加密
公钥加密：**是成对出现
公钥：公开给所有人；public key
私钥：自己留存，必须保证其私密性；secret key
特点：用公钥加密数据，只能使用与之配对的私钥解密；反之亦然
功能：
数字签名：主要在于让接收方确认发送方身份
对称**交换：发送方用对方的公钥加密一个对称**后发送给对方
数据加密：适合加密较小数据
缺点：**长，加密解密效率低下
算法：
RSA（加密，数字签名）,DSA（数字签名）,ELGamal
具体实现：
▲基于一对公钥/**对
用**对中的一个加密，另一个解密
▲实现加密
接收者
生成公钥/**对：P和S
公开公钥P，保***S
发送者
使用接收者的公钥来加密消息M
将P(M)发送给接收者
接收者
使用**S来解密：M=S(P(M))
单项加密
将任意数据缩小成固定大小的“指纹”
任意长度输入
固定长度输出
若修改数据，指纹也会改变（“不会产生冲突”）
无法从指纹中重新生成数据（“单向”）
功能：数据完整性
常见算式
md5: 128bits、sha1: 160bits、sha224
sha256、sha384、sha512
常用工具
md5sum | sha1sum [ --check ] file
openssl、gpg
rpm -V
**交换
**交换：IKE（Internet Key Exchange ）
公钥加密：
DH (Deffie-Hellman)：
DH：
1、A: a,p协商生成公开的整数a,大素数p
B: a,p
2、A:生成隐私数据:x (x<p )，计算得出a^x%p，发送给B
B:生成隐私数据:y,计算得出a^y%p，发送给A
3、A:计算得出（a^y%p）^x = a^xy%p，生成为**
B:计算得出（a^x%p）^y = a^xy%p, 生成为**
此时，A和B便生成了一个相同的**，注意这个**交换协议算法只能用于**的交换，而不能用于消息的加密处理，当双方确定要用的**后，要使用其他的对称加密操作实际加密和解密数据
****************************************************************************************************
注意，以上所说的加密算法和协议虽然能够实现两个两个计算机之间的加密通信，可是保证不了其他计算机的干预消息。
例如：A和B是互联网上的两台主机，A拥有自己的私钥，B拥有自己的私钥，此时如若A要给B发送消息，但是第一次它并不知道谁是B，如果此时有另一台机器C告诉A说我就是B，然后把自己的公钥发送给A，A此时还以为和它通信的真的是B，然而却是A和C在通信。
那么问题来了，如何确定B的身份呢？如果此时有一个双方都信任的第三方机构，由它来确认B的身份，那么问题就可以解决了，随之而来的是谁来确定这个第三方机构的身份呢，如果是一个假的机构呢？所以还需要这个机构的上级来确定它，知道到了顶层。当然这个顶层是我们所有人在心底都默认知道和了解的。
说了这么多，这个所谓的第三方机构就叫做CA，当CA每确认一台机器的时候，就会给它颁发一个证书，具体如下:
CA和证书
PKI: Public Key Infrastructure
签证机构：CA（Certificate Authority）
***构：RA
证书吊销列表：CRL
证书存取库：
X.509：定义了证书的结构以及认证协议标准
版本号
***
签名算法
颁发者
有效期限
主体名称
主体公钥
CRL分发点
扩展信息
发行者签名
证书类型：
证书授权机构的证书
服务器
用户证书
获取证书两种方法：
使用证书授权机构
生成签名请求（csr）
将csr发送给CA
从CA处接收签名
自签名的证书
自已签发自己的公钥
证书签发过程：如下图所示
1、A将自己的公钥发送给CA
2、CA在确定A的身份后，会将证书颁发给A，其中过程如下
1）CA会将应有内容整合到证书上，证书的内容结构如上。
2）然后将此内容使用单向加密算法生成特征码（用于验证证书完整性）
3）最后，CA会使用自己的私钥来对此特征吗进行加密，生成数字签名（用来验证是否为CA签署的证书），然后发给A
3）B的过程与A相同
当B验证A的身份时，就是通过证书来验证的，步骤如下
1）使用CA的公钥来解密数字签名，如果成功，则验证了CA身份
2）利用相同的单项加密算法来计算证书内容结构的特征码，与原来的特征码相比较，如果相同，则保证了证书的完整性
3）从证书内容中取出A的公钥
加密通信过程详解：
1）
第一阶段：ClientHello：客户端向服务器端发起加密通信的请求
向服务器发送自己支持的协议版本，比如tls1.2
客户端生成一个随机数，稍后用户生成”会话**“
自己支持的各种加密算法，比如AES，RSA；、
支持的压缩算法；
第二阶段：ServerHello（回应）
确认使用的加密通信协议版本，比如tls1.2；（如果版本不一样，则拒绝通信）
服务器端生成一个随机数，主要在稍后用户生成”会话**“
确认使用的加密方法
发送服务器证书
索要客户端证书（不过一般服务器端都不会验证客户端）
第三阶段：
验证服务器证书，确认无误后，取出其公钥；（验证发证机构、证书签名、证书完整性、证书持有者、证书有效期、吊销列表）
发送一下信息给服务器端
一个随机数：用于服务器公钥加密
编码变更通知：表示随后的信息都将用双方商定的加密方法和**发送
客户端握手结束通知
第四阶段：
收到客户端发来的第三个随机数-pre-master-kty后，计算生成本次会话用到的会话**
向客户端发送如下消息：
编码变更通知：与上相同
服务器端握手结束通知
此时双方已经彼此确认了对方的身份，并且建立一条安全的通道，接下来就可以传输信息了。此过程如下图所示
（1）A-->B
1）使用单向加密算法计算要传输的数据的特征码（并没有对原数据内容加密）
2）使用自己的私钥来加密这段特征码生成数字签名
3）使用对称加密算法加密上面的所有数据（包括原数据，特征码，数字签名），将生成的对称加密的密码附加在加密过的数据后面
4）使用B的公钥来加密这段对称加密的密码，并将以上所有数据发送给B
（2）B收到A发送的数据后
1）使用B的要来解密对称加密的密码（如果可以解密，则保证接收放是B）
2）利用解密过的对称加密密码来解密这段数据
3）解密后通过利用A的公钥来解密数字签名（如果可以，则保证了数据是从A发的）
4）此时，呈现在B的有两样东西，一个是原数据，还有一个是特征码。且原数据是没有加密的。此时B需要使用相同的单项加密算法对此时的原数据计算特征码，与A发送过来的特征码相比较，如果相等，则保证了原数据的完整性。
至此。信息的加密与解密过程完成。
总结：
在以上所述的过程中，个人认为有几点需要强调：
1）单项加密并不加密原数据，只是为了计算原数据的特征码。用于数据的完整性校验
2）对称加密算法加密和解密都是用同一个**。用于加密数据
3）公钥加密加密的是特征码。用于生成数字签名
4）证书的颁发和验证过程和数据的传输过程是两个过程
转载于:https://blog.51cto.com/dashui/1856324