常见加密算法及常见加密算法原理

简介

在早期，互联网通信是直接以明文进行传输，几乎没任何安全性可言，在你发送数据到接收者手上，经过n个网络设备，在传输过程中，数据可能被某些不怀好意的人截取，造成数据泄密甚至被修改。

美国NIST针对互联网数据安全，提出了几个要求：
1. 数据保密性：数据保密性和隐私性；确保信息不被别人获取，个人存储的信息不能被别人收集到；
2. 数据完整性：数据完整性确保数据和程序只能以特定权限的进行授权和改变，只能授权之后才能改变或者被改变；确保系统以一种正常的方式执行预定的功能，不会因别人的介入改变方向；
3. 可用性：工作迅速，可正常使用的情况并获取到信息；

针对以上几个安全要求，对应的解决方案出现，解决方案提出使用技术和服务解决数据安全问题。
技术（加密和解密）
服务（用于抵御攻击的服务，也即是为了上述安全目标而特地设计的安全服务）

基本概念

加密：将数据转换成不能直接读取的形式（即密文）的过程叫加密。数据加密的基本过程就是对原来为明文的文件或数据按某种加密算法配合密钥进行处理，使其成为不可读的一段代码，通常称为"密文"，使其只能在输入相应的密钥之后才能显示出本来内容，通过这样的途径来达到保护数据不被非法人窃取、阅读的目的。
解密：加密的逆过程，使用密钥配合加密算法，转换成明文内容。

大多数加密都分为：对称式加密、非对称式加密和单向加密：

对称式加密：
加密和解密采用同一密钥的加密方式。加密时，使用密钥配合算法加密。解密时，使用对应的密钥配合算法，得出解密后的数据。常见的对称加密有：DES、3DES、AES、DH。举个简单例子：通信双方约定密钥为“123”，加密算法采用AES，接受者收到加密后的密文后，使用AES算法+密钥“123”即可完成解密。使用对称式加密和解密速度很快。适合用于加密数据。对称式加密由于加密解密使用同一密钥，所以如何安全的在互联网传输密钥，是对称式加密所面临的问题。

非对称式加密
也称为公钥或私钥加密，非对称加密的密钥是成对出现的，分为私钥和公钥。公钥从私钥提取出，正如其名，私钥只能保存起来自己用，不能随意泄密，公钥是公开的，任何人都能得到。公钥和私钥都可以用于加密，但是，如果你用公钥加密，只能使用私钥解密；同样，如果用私钥解密，只能使用公钥解密。非对称加密对资源消耗大，所以一般不用于加密数据。但使用非对称式加密可以很到的解决对称式加密的短板，传输密钥。而且非对称式加密可以解决身份证明问题。

单向加密
这种加密严格意思上算不上加密，也常被称为散列运算，用于对数据生成独一无二的校验码，对于校验码叫法很多（如特征码，指纹信息）这类加密有个特点，就是具有雪崩效应，对任何数据，就算你改动一个标点符号，改动前和改动后使用算法计算出来的结果是翻天覆地的变化。但只要数据没发生改动，使用单向加密算法计算出来的值是不会发生改变的，所以使用单向加密能很好的解决数据完整性的问题。

数据加密分析：
以上三种算法各有各自的优点和缺点，在如今复杂的网络环境中单凭通过一个加密方式来确保数据安全是不科学的
如，通信双方使用对称式加密来完成数据加密。但通信双方如何确保用来加密和解密的密钥在网络中传输不被窃取呢？如果单单使用公钥私钥来加密数据，因为公钥加解密所消耗的资源实在太大，而且不能抵御中间人攻击。基于以上各种问题，现在的网络通信过程，通常使用各算法的优势，配合各种服务组合来完成数据的加密传输。

方案1：
考虑到对称加密速度快，又考虑到公钥加密能验证身份的优点，我们先对这2个算法配合使用分析一下：
首先A和B两个进程进行通信，A要发送数据给B，可以首先对数据进行对称加密，进一步考虑，对称式加密的密钥怎么安全的传送呢？可以使用公钥加密来解决这个问题，我们使用对方的公钥来加密这段对称式加密的密钥，这样只有对方的私钥能解锁这段数据；数据的收取者解密时，将使用自己的私钥解密第一层，得到对称密钥后加密的数据，再使用对称密钥解密，这样就能获得最终数据

方案2：
方案1的加密方法只保证了数据的安全性，但是数据的完整性、一致性和来源可靠并未解决。对于数据的完整性和一致性，我们可以通过单向加密来解决，前面说了，只要数据没发生改变，那么使用相同算法算出来的值，肯定是一样的，那么我们可以在数据传送前，先使用单向加密方法，算出独一无二的校验码,这个校验码称为：信息摘要（Message Digest)附加在数据后面，然后使用自己的私钥来加密这个信息摘要，这种使用私钥加密信息摘要产生的加密后的信息摘要，我们称为数字签名（Signature)由此来看数字签名能保证数据来源可靠性（因为使用私钥加密，只要对应的公钥能解密）数据的完整性和一致性（私钥加密的是信息摘要，解密后得出的信息摘要我们只要使用同样的单向加密算出数据部分的信息摘要，经过对比，如果相同则证明数据是完整，未被修改的）用户获得数字签名后的数据，首先使用数据来源方的公钥解密，这样获得了数据和信息摘要部分，并确认了数据来源的可靠性。由于这时候数据部分是没有被加密的，所以用户也可以使用同种单向加密算法计算出摘要信息，然后对比来源方的摘要信息和自己计算出的摘要信息，如果相等则证明数据完全未被修改过，是完整一致的。

方案3：
方案2中并未对数据部分进行加密，所以方案3综合方案1和方案2的优点，
加密步骤如下：
1.先对数据进行单向加密，得出信息摘要，可以验证数据完整性
2.使用私钥加密信息摘要，得出数字签名，附加在数据后面，可以验证来源合法
3.使用方案1的对称式加密，对数据和数字前面加密，得出对称密钥
4.使用对方的公钥加密这个对称密钥，传送给对方，只有对方的私钥能解密
解密步骤如下
1.先使用自己的私钥解开对称加密的密钥
2.使用该密钥，解密对称加密，得出数字签名和数据
3.使用对方的公钥解密数字签名，得到信息摘要，并且能解开，证明身份得到验证。
4.对数据部分进行单向加密，得出信息摘要，然后和解密后的信息摘要作对比，如果一致，那么数据完整性得到验证。

中间人攻击
前面介绍了加密传输的各种方案，方案3比较理想，基本上都验证了。但安全并不是绝对的，方案3也有缺陷，没办法验证对方的公钥是否可靠。
如果公钥不可靠带来什么后果？
假设出现这样的情景：
Alice要和Bob通信，Alice最后把数据用Bod的公钥加密后，发送给Bod，Bob收到后按照方案3那样解密，这样看起来好像没问题，但如果Bob收到的数据其实不是Alice发送过来的呢？Alice发送的数据在传输过程中，如果被一个中间人，如eve，eve截取了Alice的数据之后，虽然不能轻易破解，但是eve对自己的一个恶意程序按照Alice那样对数据加密后用Bob的公钥加密对称密钥后发给Bob并声称自己就是Alice，同样对Alice声称自己是Bob，这样Alice和Bob的通信其实是跟eve在进行，但是Alice和Bob都不知道。这就是中间人攻击。
那么，如何解决这个漏洞呢，其实Bob只要确保公钥是Alice的就可以了，在解密数字签名的时候，如果使用真正的Alice公钥，是不可能解密eve发过来的数字签名。那么如何保证公钥的可靠性呢？CA就是为了保证公钥的可靠而生。

公钥基础设施PKI、CA
PKI（Public Key Infrastructure）公钥基础设施是提供公钥加密和数字签名服务的系统或平台，目的是为了管理密钥和证书。
PKI 主要包括四个部分：
签证机构：CA
注册机构：RA
证书吊销列表：CRL
证书存取库：

CA(Certificate Authority）数字证书认证中心，常称为证书颁发机构，申请者把自己的公钥和一些个人信息（如国家、姓名、单位等等）给CA，CA负责审核信息，通过后，CA会对这些信息生成一个摘要信息，然后用自己的私钥加密整个摘要信息，这样申请者的数字签名就出来了，然后CA会在数字签名上再加上一些自己的信息。(如CA的机构名称，CA层次路径等)以及该证书的信息(如证书有效期限)，就得到了所谓的数字证书。

其实简单来理解，CA作用就是保证公钥是可靠的，把自己的公钥给CA，CA帮你生成一张数字证书，该证书不但有你的公钥信息，而且有其他的一些信息

用户信任CA,会获取该CA的公钥，由CA颁发的数字证书都就被CA加密，要有CA的公钥能解密。
证书信任链：
实际上，CA被分成根CA和子CA，根CA的证书是自签的，系统安装时候就应该提供，子CA的证书是上一级CA签署的。
根CA是通过自签署数字证书的方式标榜自己的可信性和合法性，第一级子CA由根CA颁发合法数字证书，第二级直至所有的子CA都由上一级子CA颁发数字证书。对于多级子CA只需要信任根CA即可，因为获取了根CA的公钥，可以解密第一级子CA的证书并获取验证第一级子CA的公钥，层层递进，最终获取到为申请者颁发数字证书的机构并获取它的公钥。
正是这些根CA和子CA组成了PKI。 信任CA后，每次接收到需要解密的数字证书时，还要去该颁发机构指定网站的证书吊销列表（CRL）中查询该证书是否被吊销，对于吊销后的证书应该不予以信任，这是信任CA的第二个作用。导致证书被吊销的可能性不少，例如申请者的私钥被黑客获取，申请者申请吊销等。

数字证书
TLS和SSL使用的证书格式都是x509，pgp使用的数字证书不是X509
数字证书中包含的信息有：申请者的公钥，证书有效期，证书合法拥有人，证书如何被使用，CA的信息，CA对申请者信息的数字签名

SSL握手机制。

SSL的握手过程（SSL hardshake)
HTTPS通过SSL协议实现安全加密
SSL单向握手过程，服务端不需要客户端提供数字证书。

第一步：Visitor生成一个随机数，客户端支持的加密方法，发送给服务端
第二步：Server确认双方使用的加密方法，以及一个服务端生成的随机数（Server random）、以及把服务端的数字证书发送个客户端
第三步：客户端验证数字证书，用CA公钥解密证书，查看证书有效期，和是否被吊销，验证通过后，生成一个新的随机数，（称为预备主密钥Pre-master secret），并使用Server的公钥加密预备主密钥发给Server。公钥自然在证书里提取。
第四步：Server使用自己的私钥，解密Visitor发来的预备主密钥。
第五步：Visitor和Server双方都具有了(客户端随机数+服务端随机数+预备主密钥)，它们两者都根据约定的加密方法，使用这三个随机数生成对称密钥——主密钥（也称为对话密钥session key），用来加密接下来的整个对话过程。
之后所有的数据在这次会话中只需要使用“对话密钥”即可，不需要多余的机制

注意:
1.在SSL握手机制中，需要三个随机数（客户端随机数+服务端随机数+预备主密钥）；
2.至始至终客户端和服务端只有一次非对称加密动作——客户端使用证书中获得的服务端公钥加密预备主密钥。
3.上述SSL握手机制的前提单向验证，无需验证客户端，如果需要验证客户端则可能需要客户端的证书或客户端提供签名等。
4.如果像网银那种情况，银行需要验证客户端的数字证书，通常那种证书都是银行为用户签署的，一般保存在网银盾上，通过网银盾的密码来保护，证书里保存着客户端的公钥。