加密算法 DES,3DES,AES 、RSA,DSA,ECC、MD5,SHA1,HMAC

Qter

加密技术通常分为两大类:"对称式"和"非对称式"。

对称性加密算法：对称式加密就是加密和解密使用同一个密。

非对称算法：非对称式加密就是加密和解密所使用的不是同一个密钥，通常有两个密钥，称为"公钥"和"私钥"，它们两个必需配对使用，否则不能打开加密文件。
散列算法：又称哈希函数，是一种单向加密算法。散列(Hash)函数它对不同长度的输入消息，产生固定长度的输出。这个固定长度的输出称为原输入消息的"散列"或"消息摘要"(Message digest)，用来做签名。

1. 加密算法是可逆的，用来对敏感数据进行保护。散列算法(签名算法、哈希算法)是不可逆的，主要用于身份验证。
2. 对称加密算法使用同一个密匙加密和解密，速度快，适合给大量数据加密。对称加密客户端和服务端使用同一个密匙，存在被抓包破解的风险。
3. 非对称加密算法使用公钥加密，私钥解密，私钥签名，公钥验签。安全性比对称加密高，但速度较慢。非对称加密使用两个密匙，服务端和客户端密匙不一样，私钥放在服务端，黑客一般是拿不到的，安全性高。

对称加密：
DES（Data Encryption Standard）：数据加密标准，速度较快，适用于加密大量数据的场合。一种分组数据加密技术（先将数据分成固定长度的小数据块，之后进行加密）

3DES（Triple DES）：是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高。

AES（Advanced Encryption Standard）：高级加密标准，是下一代的加密算法标准，速度快，安全级别高；AES是一个使用128为分组块的分组加密算法，分组块和128、192或256位的密钥一起作为输入，对4×4的字节数组上进行操作。众所周之AES是种十分高效的算法，尤其在8位架构中，这源于它面向字节的设计。AES 适用于8位的小型单片机或者普通的32位微处理器,并且适合用专门的硬件实现，硬件实现能够使其吞吐量（每秒可以到达的加密/解密bit数）达到十亿量级。同样，其也适用于RFID系统。


非对称加密：
RSA：由 RSA 公司发明，是一个支持变长密钥的公共密钥算法，需要加密的文件块的长度也是可变的。RSA在国外早已进入实用阶段，已研制出多种高速的RSA的专用芯片。

DSA（Digital Signature Algorithm）：数字签名算法，是一种标准的 DSS（数字签名标准），严格来说不算加密算法。

ECC（Elliptic Curves Cryptography）：椭圆曲线密码编码学。ECC和RSA相比，具有多方面的绝对优势。

散列算法（签名算法）：
MD5：MD5是一种不可逆的加密算法，目前是最牢靠的加密算法之一，尚没有能够逆运算的程序被开发出来，它对应任何字符串都可以加密成一段唯一的固定长度的代码。
SHA1：安全散列算法（英语：Secure Hash Algorithm，缩写为SHA）它对长度小于264的输入，产生长度为160bit的散列值。
HMAC：是密钥相关的哈希运算消息认证码（Hash-based Message Authentication Code）,HMAC运算利用哈希算法，以一个密钥和一个消息为输入，生成一个消息摘要作为输出。也就是说HMAC是需要一个密钥的。所以，HMAC_SHA1也是需要一个密钥的，而SHA1不需要。
-----
这几种算法只生成一串不可逆的密文，经常用其效验数据传输过程中是否经过修改，因为相同的生成算法对于同一明文只会生成唯一的密文，若相同算法生成的密文不同，则证明传输数据进行过了修改。通常在数据传说过程前，使用MD5和SHA1算法均需要发送和接收数据双方在数据传送之前就知道密匙生成算法，而HMAC与之不同的是需要生成一个密匙，发送方用此密匙对数据进行摘要处理（生成密文），接收方再利用此密匙对接收到的数据进行摘要处理，再判断生成的密文是否相同。

-----SHA家族---
SHA家族的五个算法，分别是SHA-1、SHA-224、SHA-256、SHA-384，和SHA-512
SHA-1:SHA-1可以生成一个被称为消息摘要的160位（20字节）散列值，散列值通常的呈现形式为40个十六进制数。
SHA-1在许多安全协定中广为使用，包括TLS和SSL、PGP、SSH、S/MIME和IPsec，曾被视为是MD5（更早之前被广为使用的杂凑函数）的后继者。
人们一般把哈希值位数长度作为重要的区别，SHA-1是160位的哈希值，而SHA-2是组合值，有不同的位数，其中最受欢迎的是256位。
SHA-2:属于SHA算法之一，是SHA-1的后继者。其下又可再分为六个不同的算法标准，包括了：SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA-512/256。
以它们的摘要长度（以位元计算）加在原名后面来命名：SHA-256，SHA-384和SHA-512。

总结

对于各种加密算法的选用：由于对称加密算法的密钥管理是一个复杂的过程，密钥的管理直接决定着他的安全性，因此当数据量很小时，我们可以考虑采用非对称加密算法。
在实际的操作过程中，我们通常采用的方式是：采用非对称加密算法管理对称算法的密钥，然后用对称加密算法加密数据，这样我们就集成了两类加密算法的优点，既实现了加密速度快的优点，又实现了安全方便管理密钥的优点。
如果在选定了加密算法后，那采用多少位的密钥呢？
一般来说，密钥越长，运行的速度就越慢，应该根据的我们实际需要的安全级别来选择，一般来说，RSA建议采用1024位的数字，ECC建议采用160位，AES采用128为即可。

Qter

加密算法(DES,AES,RSA,MD5,SHA1,Base64)比较和项目应用

加密技术通常分为两大类:"对称式"和"非对称式"。

对称性加密算法：对称式加密就是加密和解密使用同一个密钥。信息接收双方都需事先知道密匙和加解密算法且其密匙是相同的，之后便是对数据进行加解密了。对称加密算法用来对敏感数据等信息进行加密。

非对称算法：非对称式加密就是加密和解密所使用的不是同一个密钥，通常有两个密钥，称为"公钥"和"私钥"，它们两个必需配对使用，否则不能打开加密文件。发送双方A,B事先均生成一堆密匙，然后A将自己的公有密匙发送给B，B将自己的公有密匙发送给A，如果A要给B发送消 息，则先需要用B的公有密匙进行消息加密，然后发送给B端，此时B端再用自己的私有密匙进行消息解密，B向A发送消息时为同样的道理。

散列算法：散列算法，又称哈希函数，是一种单向加密算法。在信息安全技术中，经常需要验证消息的完整性，散列(Hash)函数提供了这一服务，它对不同长度的输入消息，产生固定长度的输出。这个固定长度的输出称为原输入消息的"散列"或"消息摘要"(Message digest)。散列算法不算加密算法，因为其结果是不可逆的，既然是不可逆的，那么当然不是用来加密的，而是签名。

对称性加密算法有：AES、DES、3DES
用途：对称加密算法用来对敏感数据等信息进行加密

DES（Data Encryption Standard）：数据加密标准，速度较快，适用于加密大量数据的场合。

3DES（Triple DES）：是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高。

AES（Advanced Encryption Standard）：高级加密标准，是下一代的加密算法标准，速度快，安全级别高；AES是一个使用128为分组块的分组加密算法，分组块和128、192或256位的密钥一起作为输入，对4×4的字节数组上进行操作。众所周之AES是种十分高效的算法，尤其在8位架构中，这源于它面向字节的设计。AES 适用于8位的小型单片机或者普通的32位微处理器,并且适合用专门的硬件实现，硬件实现能够使其吞吐量（每秒可以到达的加密/解密bit数）达到十亿量级。同样，其也适用于RFID系统。

非对称性算法有：RSA、DSA、ECC

RSA：由 RSA 公司发明，是一个支持变长密钥的公共密钥算法，需要加密的文件块的长度也是可变的。RSA在国外早已进入实用阶段，已研制出多种高速的RSA的专用芯片。

DSA（Digital Signature Algorithm）：数字签名算法，是一种标准的 DSS（数字签名标准），严格来说不算加密算法。

ECC（Elliptic Curves Cryptography）：椭圆曲线密码编码学。ECC和RSA相比，具有多方面的绝对优势，主要有：抗攻击性强。相同的密钥长度，其抗攻击性要强很多倍。计算量小，处理速度快。ECC总的速度比RSA、DSA要快得多。存储空间占用小。ECC的密钥尺寸和系统参数与RSA、DSA相比要小得多，意味着它所占的存贮空间要小得多。这对于加密算法在IC卡上的应用具有特别重要的意义。带宽要求低。当对长消息进行加解密时，三类密码系统有相同的带宽要求，但应用于短消息时ECC带宽要求却低得多。带宽要求低使ECC在无线网络领域具有广泛的应用前景。

散列算法（签名算法）有：MD5、SHA1、HMAC
用途：主要用于验证，防止信息被修。具体用途如：文件校验、数字签名、鉴权协议

MD5：MD5是一种不可逆的加密算法，目前是最牢靠的加密算法之一，尚没有能够逆运算的程序被开发出来，它对应任何字符串都可以加密成一段唯一的固定长度的代码。

SHA1：是由NISTNSA设计为同DSA一起使用的，它对长度小于264的输入，产生长度为160bit的散列值，因此抗穷举(brute-force)性更好。SHA-1设计时基于和MD4相同原理,并且模仿了该算法。SHA-1是由美国标准技术局（NIST）颁布的国家标准，是一种应用最为广泛的Hash函数算法，也是目前最先进的加密技术，被政府部门和私营业主用来处理敏感的信息。而SHA-1基于MD5，MD5又基于MD4。

HMAC：是密钥相关的哈希运算消息认证码（Hash-based Message Authentication Code）,HMAC运算利用哈希算法，以一个密钥和一个消息为输入，生成一个消息摘要作为输出。也就是说HMAC是需要一个密钥的。所以，HMAC_SHA1也是需要一个密钥的，而SHA1不需要。

其他常用算法：

Base64：其实不是安全领域下的加密解密算法，只能算是一个编码算法，通常用于把二进制数据编码为可写的字符形式的数据，对数据内容进行编码来适合传输(可以对img图像编码用于传输)。这是一种可逆的编码方式。编码后的数据是一个字符串，其中包含的字符为：A-Z、a-z、0-9、+、/，共64个字符(26 + 26 + 10 + 1 + 1 = 64，其实是65个字符，“=”是填充字符。Base64要求把每三个8Bit的字节转换为四个6Bit的字节(3*8 = 4*6 = 24)，然后把6Bit再添两位高位0，组成四个8Bit的字节，也就是说，转换后的字符串理论上将要比原来的长1/3。原文的字节最后不够3个的地方用0来补足，转换时Base64编码用=号来代替。这就是为什么有些Base64编码会以一个或两个等号结束的原因，中间是不可能出现等号的，但等号最多只有两个。其实不用"="也不耽误解码，之所以用"="，可能是考虑到多段编码后的Base64字符串拼起来也不会引起混淆。)
Base64编码是从二进制到字符的过程，像一些中文字符用不同的编码转为二进制时，产生的二进制是不一样的，所以最终产生的Base64字符也不一样。例如"上网"对应utf-8格式的Base64编码是"5LiK572R"， 对应GB2312格式的Base64编码是"yc/N+A=="。
标准的Base64并不适合直接放在URL里传输，因为URL编码器会把标准Base64中的“/”和“+”字符变为形如“%XX”的形式，而这些“%”号在存入数据库时还需要再进行转换，因为ANSI SQL中已将“%”号用作通配符。
为解决此问题，可采用一种用于URL的改进Base64编码，它不在末尾填充'='号，并将标准Base64中的“+”和“/”分别改成了“-”和“_”，这样就免去了在URL编解码和数据库存储时所要作的转换，避免了编码信息长度在此过程中的增加，并统一了数据库、表单等处对象标识符的格式。
另有一种用于正则表达式的改进Base64变种，它将“+”和“/”改成了“!”和“-”，因为“+”，“*”以及前面在IRCu中用到的“[”和“]”在正则表达式中都可能具有特殊含义。
此外还有一些变种，它们将“+/”改为“_-”或“._”（用作编程语言中的标识符名称）或“.-”（用于XML中的Nmtoken）甚至“_:”（用于XML中的Name）。

​HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL(SSL使用40 位关键字作为RC4流加密算法，这对于商业信息的加密是合适的。)，因此加密的详细内容就需要SSL。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间），提供了身份验证与加密通讯方法，现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。它的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。

项目应用总结：
1. 加密算法是可逆的，用来对敏感数据进行保护。散列算法(签名算法、哈希算法)是不可逆的，主要用于身份验证。
2. 对称加密算法使用同一个密匙加密和解密，速度快，适合给大量数据加密。对称加密客户端和服务端使用同一个密匙，存在被抓包破解的风险。
3. 非对称加密算法使用公钥加密，私钥解密，私钥签名，公钥验签。安全性比对称加密高，但速度较慢。非对称加密使用两个密匙，服务端和客户端密匙不一样，私钥放在服务端，黑客一般是拿不到的，安全性高。
4. Base64不是安全领域下的加解密算法，只是一个编码算法，通常用于把二进制数据编码为可写的字符形式的数据，特别适合在http，mime协议下的网络快速传输数据。UTF-8和GBK中文的Base64编码结果是不同的。采用Base64编码不仅比较简短，同时也具有不可读性，即所编码的数据不会被人用肉眼所直接看到，但这种方式很初级，很简单。Base64可以对图片文件进行编码传输。
5. https协议广泛用于万维网上安全敏感的通讯，例如交易支付方面。它的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。
6. 大量数据加密建议采用对称加密算法，提高加解密速度；小量的机密数据，可以采用非对称加密算法。在实际的操作过程中，我们通常采用的方式是：采用非对称加密算法管理对称算法的密钥，然后用对称加密算法加密数据，这样我们就集成了两类加密算法的优点，既实现了加密速度快的优点，又实现了安全方便管理密钥的优点。
7. MD5标准密钥长度128位（128位是指二进制位。二进制太长，所以一般都改写成16进制，每一位16进制数可以代替4位二进制数，所以128位二进制数写成16进制就变成了128/4=32位。16位加密就是从32位MD5散列中把中间16位提取出来）；sha1标准密钥长度160位(比MD5摘要长32位)，Base64转换后的字符串理论上将要比原来的长1/3。

Qter

AES：更快，兼容设备，安全级别高；

SHA1：公钥后处理回传

DES：本地数据，安全级别低

RSA：非对称加密，有公钥和私钥

MD5：防篡改



相关：

公开密钥加密（英语：public-key cryptography，又译为公开密钥加密），也称为非对称加密（asymmetric cryptography），一种密码学算法类型，在这种密码学方法中，需要一对密钥，一个是私人密钥，另一个则是公开密钥。这两个密钥是数学相关，用某用户密钥加密后所得的信息，只能用该用户的解密密钥才能解密。如果知道了其中一个，并不能计算出另外一个。因此如果公开了一对密钥中的一个，并不会危害到另外一个的秘密性质。称公开的密钥为公钥；不公开的密钥为私钥。



DES现在已经不是一种安全的加密方法，主要因为它使用的56位密钥过短。1999年1月，distributed.net与电子前哨基金会合作，在22小时15分钟内即公开破解了一个DES密钥。也有一些分析报告提出了该算法的理论上的弱点，虽然在实际中难以应用。为了提供实用所需的安全性，可以使用DES的派生算法3DES来进行加密，虽然3DES也存在理论上的攻击方法。在2001年，DES作为一个标准已经被高级加密标准（AES）所取代。另外，DES已经不再作为国家标准科技协会（前国家标准局）的一个标准。



高级加密标准（英语：Advanced Encryption Standard，缩写：AES），在密码学中又称Rijndael加密法，是美国联邦政府采用的一种区块加密标准。这个标准用来替代原先的DES，已经被多方分析且广为全世界所使用。经过五年的甄选流程，高级加密标准由美国国家标准与技术研究院（NIST）于2001年11月26日发布于FIPS PUB 197，并在2002年5月26日成为有效的标准。2006年，高级加密标准已然成为对称密钥加密中最流行的算法之一。







MD5和SHA1是2种加密算法，用于计算出一段不可逆向计算的数值，以此来验证该文件是否被修改的.

它可以帮你验证从网上下载下来的windows7安装程序是否与发布人发布的东西完全一致，也就是帮助你验证这个程序有没有经过他人（非发布人）的修改。






aes/des加密速度快,适合大量数据,des容易破解,一般用3重des,后来又出现了更快更安全的aes
rsa是公钥加密,速度慢,只能处理少量数据,优点是公钥即使在不安全的网络上公开,也能保证安全
常见情况是双方用rsa协商出一个密钥后通过aes/3des给数据加密




SHA-1
在1993年，安全散列算法（SHA）由美国国家标准和技术协会(NIST)提出，并作为联邦信息处理标准（FIPS PUB 180）公布；1995年又发布了一个修订版FIPS PUB 180-1，通常称之为SHA-1。SHA-1是基于MD4算法的，并且它的设计在很大程度上是模仿MD4的。现在已成为公认的最安全的散列算法之一，并被广泛使用。

原理
SHA-1是一种数据加密算法，该算法的思想是接收一段明文，然后以一种不可逆的方式将它转换成一段（通常更小）密文，也可以简单的理解为取一串输入码（称为预映射或信息），并把它们转化为长度较短、位数固定的输出序列即散列值（也称为信息摘要或信息认证代码）的过程。

单向散列函数的安全性在于其产生散列值的操作过程具有较强的单向性。如果在输入序列中嵌入密码，那么任何人在不知道密码的情况下都不能产生正确的散列值，从而保证了其安全性。ＳＨＡ将输入流按照每块５１２位（６４个字节）进行分块，并产生２０个字节的被称为信息认证代码或信息摘要的输出。

该算法输入报文的最大长度不超过264位，产生的输出是一个160位的报文摘要。输入是按512 位的分组进行处理的。SHA-1是不可逆的、防冲突，并具有良好的雪崩效应。

通过散列算法可实现数字签名实现，数字签名的原理是将要传送的明文通过一种函数运算（Hash）转换成报文摘要（不同的明文对应不同的报文摘要），报文摘要加密后与明文一起传送给接受方，接受方将接受的明文产生新的报文摘要与发送方的发来报文摘要解密比较，比较结果一致表示明文未被改动，如果不一致表示明文已被篡改。

Qter

散列算法：SHA-1，SHA-2和SHA-256之间的区别文|李伟志
       随着SSL证书的普及，以“SHA”开头的算法的知名度也越多越高，但并不是很多人能够完全能分清“SHA”所有的算法，本文将会围绕“SHA”展开分析，深入了解SSL证书是如果通过散列算法来完成签名。在细说“SHA”之前，首先要了解一个重要的名称——HASH（哈希）。


        什么是HASH（哈希）？
        HASH算法将任意长度的二进制值映射为较短的固定长度的二进制值，这个小的二进制值称为哈希值。例如句子“那只敏捷的棕色狐狸跳过了懒惰的狗，”通过一种称为CRC32的特定算法运行，将会产生结果“07606bb6”。而这个结果被称为HASH（哈希）。
        一般情况下，电脑可以对hash进行识别、比较、或对文件和字符串进行数据计算。计算机会先对HASH进行计算，然后与原始文件进行校验。
        HASH算法的重要特征是其确定性。上述的列子，在任何一台电脑使用任意的hash算法得出的结果都是一样的。
        HASH算法的应用有多种，可用于计算机视觉数据库中存储密码。
        目前，HASH算法的方式有数百种，但它们都有特定的用途：有些是针对某些类型的数据进行了优化，一些则针对速度，安全性等。
        而本文提到的“SHA”算法，是HASH算法的一种。SHA表示加密散列算法，用于网络加密安全。
        对于加密散列算法的最重要的因素是他们产生不可逆的和独特的哈希值。不可逆性，数据一旦产生哈希值，那么就不可能通过单一的哈希值解出原始的数据。独特性，两个不懂的数据是不能产生同样的哈希值。下面将分为这两个特性为什么如此重要。
        注意：为了更容易阅读和理解这篇文章，下文使用了一个示例数据字符串和散列算法，该算法比实际使用的要短得多。到目前为止，所看到的哈希值并不是任何类型的哈希。



数字签名
        SSL / TLS协议是为客户端到服务端之间搭建一条安全的网络数据传输通道。为了简单理解，很多人把SSL直接解析为“加密”。但是，SSL还有另外重要的功能——身份验证。SSL证书文件的任务之一是提供身份验证所需的信息，具体而言，SSL证书将特定的公钥连接到安全标识。
       SSL / TLS协议是使用非对称加密来确保安全连接。这意味着有两个加密密钥：一个用于加密的公钥，另一个用于解密的私钥。每个SSL证书都包含一个公钥，客户端可以使用该密钥对数据进行加密，拥有SSL证书的所有者可以在其服务器上安全的存储一个私钥，然后对数据进行解密，安全查看数据内容。
        认证对于SSL／TLS提供的安全特性非常重要。如果没有可靠的方式验证谁拥有加密密钥，那么数据加密就没有意义了，因为客户端无法判断哪一个服务端拥有安全的密钥。如果将数据直接发给中间人的攻击者，那么密钥就没有存在的意义。
       数字签名是SSL证书提供身份验证的重要组成部分。颁发证书时，是由证书提供商（CA机构）进行数字签名（如Symantec、GlobalSign、数安时代GDCA）。该签名提供加密密钥，CA签署了SSL证书，证书没有被修改或转载。
       非对称密钥将再次被使用，但是为了签名而不是加密。从数学角度来说，签名涉及到数据和密钥组合的方式。为了让计算机在安全的情况下响应迅速，安全创建和检测签名，CA机构会先在证书生成哈希值，这比签署整个证书更有效率。
       然后，数字签名提供所需证书，证明所提供的证书是受信任CA颁发给相关网站的有效证书。
       数字签名是非常灵敏的，对文件的任何更改都会导致签名改变。同一单词的英文大小所产生的哈希值都是不同的，这就意味着其散列的结果签名也是不一样的。如果改变一千万字节的文档，将会产生完全不同的哈希。
        数字签名非常敏感——对文件的任何更改都会导致签名改变。如果我们从上一节中引用我们的示例语句，并将其完全小写（“快速的棕色狐狸跳过懒惰的狗”），得到的哈希将是完全不同的。这意味着该散列的结果签名也会不同。甚至改变一个多千字节文件会导致完全不同的哈希。
       这样，攻击者就不可能更改合法的证书或伪造类似正确的欺诈性证书。不同的哈希值意味着其签名是无效的，当客户端访问服务器是，计算机就会自动验证SSL证书，一旦遇到无效的证书，就会触发错误并阻止客户端链接
SHA-1与SHA-2
如上所述，SHA代表安全哈希算法。SHA-1和SHA-2是该算法不同的两个版本，它们的构造和签名的长度都有所不一样，但可以把SHA-2理解为SHA-1的继承者。
首先，人们一般把哈希值位数长度作为重要的区别，SHA-1是160位的哈希值，而SHA-2是组合值，有不同的位数，其中最受欢迎的是256位。
因为SHA-2有多种不同的位数，导致这个名词有一些混乱。但是无论是“SHA-2”，“SHA-256”或“SHA-256位”，其实都是指同一种加密算法。但是SHA-224”，“SHA-384”或“SHA-512”，表示SHA-2的二进制长度。还要另一种就是会把算法和二进制长度都写上，如“SHA-2 384”。
SSL行业选择SHA作为数字签名的散列算法，从2011到2015，一直以SHA-1位主导算法。但随着互联网技术的提升，SHA-1的缺点越来越突显。从去年起，SHA-2成为了新的标准，所以现在签发的SSL证书，必须使用该算法签名。
也许有人偶尔会看到SHA-2 384位的证书，很少会看到224位，因为224位不允许用于公共信任的证书，512位，不被软件支持。
初步预计，SHA-2的使用年限为五年，但也许会被提前淘汰。这需要时间来验证。
下面是SSL证书的SHA-1和SHA-2签名对比





两者在表面上似乎没有什么特别，但是数字签名对于SSL / TLS的安全性具有重要的作用。
哈希值越大，组合越多，其安全性就越高。加密哈希算法的一个重要功能是产生独特的散列，当两个不同的值或文件可以产生相同的散列，则会创建所谓的碰撞。
只有在不发生碰撞时，才能保证数字签名的安全性。碰撞对于哈希算法来说是极其危险的，因为碰撞允许两个文件产生相同的签名。当计算机检查签名时，即使该文件未真正签署，也会被计算机识别为有效的。
多种不同哈希值
每个哈希位有两个可能值：0和1。每一个独立的哈希值通过位的可能值的数量。对于SHA-256，有2的256次方种组合。这是一个庞大的数值。
哈希值越大，碰撞的机率就越小。
在技术上，有无限数量的可输入[ 1 ]，但是数量有限的。因此，每个散列算法，包括安全算法，都会发生碰撞。因为SHA-1的大小结构都碰撞的机率比较大，所以SHA-1被认为是不安全的。
迁移到SHA-2
去年，SSL行业最新证书全部迁移SHA-2，在2015 年12月31日前，CA机构仍可颁发SHA-1签名SSL证书。所以这两年，仍可看到安全SHA-1的数字签名证书。但日后，如果网站仍使用 SHA-1的SSL证书，客户端将会看到一个降级的安全指示器。在Chrome中，2016年过期的所有SHA-1证书都不会显示安全连接中的绿色挂锁，直接变成与不安全的HTTP连接相同的图标。客户端可以点击图标获取具体信息，了解详细原因，因为这与签名无关。
如果在浏览器（chrome）中看到了SHA-1证书，。要查看浏览器中该页面的内容，请访问https://sha1-2016.badssl.com





在2017年，浏览器会对SHA-1签署的证书进行更严格的安全警告，因为签名的安全性与证书的有效时间有直接关系。
保持安全的签名
随着时间的推移，对加密技术的攻击将会越来越强，其安全成本也有所降低。这使得有效的SHA-2签名将会越来越不安全。可见，安全算法防护要比实际要强，而短期的改善并不是一个长期的方案。对于特定的哈希算法来说，保持十年的安全性是不切实际。
虽然目前的SSL证书是可靠安全的数字签名。但全球的网络安全专家仍不断分析研究SHA-2和其他加密算法，日后将会推出更安全的算法。其中SHA-2的继承者已敲定为SHA-3，这两种可能是完全不同的算法，但不会影响SHA-3成为SSL行业的加密算法的选择。
作者简介：李伟志，职场作家、职业生涯咨询师。



作者：ROW供享社
链接：https://www.jianshu.com/p/68c664b663f4

Qter

AES加密的四种模式详解
https://www.cnblogs.com/liangxuehui/p/4651351.html

对称加密和分组加密中的四种模式(ECB、CBC、CFB、OFB)

一. AES对称加密:

                                                      AES加密



                         分组


二. 分组密码的填充

                                                   分组密码的填充

e.g.:

                                                         PKCS#5填充方式



三. 流密码:




四. 分组密码加密中的四种模式:
3.1 ECB模式

优点:
1.简单；
2.有利于并行计算；
3.误差不会被传送；
缺点:
1.不能隐藏明文的模式；
2.可能对明文进行主动攻击；



3.2 CBC模式：

优点：
1.不容易主动攻击,安全性好于ECB,适合传输长度长的报文,是SSL、IPSec的标准。
缺点：
1.不利于并行计算；
2.误差传递；
3.需要初始化向量IV

3.3 CFB模式：

优点：
1.隐藏了明文模式;
2.分组密码转化为流模式;
3.可以及时加密传送小于分组的数据;
缺点:
1.不利于并行计算;
2.误差传送：一个明文单元损坏影响多个单元;
3.唯一的IV;

3.4 OFB模式：

优点:
1.隐藏了明文模式;
2.分组密码转化为流模式;
3.可以及时加密传送小于分组的数据;
缺点:
1.不利于并行计算;
2.对明文的主动攻击是可能的;
3.误差传送：一个明文单元损坏影响多个单元;

Qter

iOS | 图解iOS签名背后的原理

上周我给组里做了一次“学习汇报”，其实也是组里每周都有的技术分享，每个人都有机会，这次轮到我了。那作为团队菜鸟，我该讲点什么呢？

我思前想后，突然想到自己之前老是遇到的一个棘手的问题：在真机上运行iOS工程时，工程还没跑起来，工程配置的签名（Targets > Signing & Capabilities）那里就先报错了，不管是自己的工程，第三方开源库，还是公司的项目。

虽然自己每次面向谷歌或者面向同事都可以找到答案，但为什么能解决以及为什么真机运行iOS项目需要签名，自己只能说是对它们一知半解、被它们弄得云里雾里。

不过现在我总算明白了它们背后的奥秘！如果你也有同样的困惑，往下看，保证这次让你彻底弄懂它——iOS签名背后的原理！

本文目标

阅读完本文会让你拥有轻松解决以下问题的能力：

• 如何在真机上跑自己的iOS项目，或者iOS开源库？
• 如何在真机上跑公司的iOS项目？
  

另外，本文的终极目标是：遇到任何iOS签名相关问题时，你都能够快速解决。

预备知识：数字签名 & 数字证书

在聊iOS签名之前，我们先需要了解两个预备知识，那就是在互联网世界里的签名✒️和证书📄。

可参考：数字签名和数字证书是什么？[1]——阮一峰

数字签名

数字签名一般夹带在要传输的数据中，用来防止数据被篡改。

它的底层核心是哈希混淆算法和非对称加密技术（公/私钥）。

生成

签名Signature的生成由通信中的发送方Sender进行，首先对要传输的数据Data进行哈希Hash混淆得到数据摘要Digest，然后用私钥Private Key对摘要进行加密，这样就生成了数据的签名。

验证

接收方Receiver接收来自发送方的数据和签名，对它们分别做如下处理：

• 数据：使用与发送方相同的哈希算法对数据进行混淆，得到数据摘要A；
• 签名：利用发送方加密所用私钥对应的公钥Public Key，对签名进行解密，得到数据摘要B。
  

比对摘要A和摘要B，如果相等，则说明数据没有被篡改，否则数据存在问题。

签名的生成和验证过程合在一起如下图所示，自己再分析一遍可加深理解。

带着问题往下走：

Q1: 猜想一下iOS签名和验签的过程，App开发者和App使用者中，谁是发送方，谁是接收方，传输的数据又是什么呢？

A1: App开发者是发送方，App使用者是接收方，传输的数据就是App的安装包。

Q2: 接收方如何拿到解密所用的公钥呢？

请接着往下看。

数字证书

在了解数字证书之前，我们可能马上想到的是，发送方在发送数据和签名的同时，再附带上公钥不就万事俱备了吗～如下图所示：

但是这样会引入一个新的问题：

Q1: 接收方如何确认公钥没有被其他人恶意替换呢？也就是公钥的身份不明。

这时候数字证书就该登场了。

组成内容

我们可以先看一下数字证书的组成内容，它由公钥、公钥的身份信息Identity Info以及它们的签名B组成。

注意：加密公钥数据所用的私钥又是另外一个公私钥组合了，它是由权威的认证机构（Certificate Authority，CA）颁发的。

公钥包装在数字证书中传递

这下，原来发送方发送的内容由数据+签名+公钥，变成了数据+签名+证书。

证书里包含了接收方解密签名A所需的公钥，除此之外，证书里还有公钥的身份信息和签名B：

• 身份信息的存在则可以消除公钥身份不明的隐患；
• 而签名B则对公钥及其身份信息未被篡改做了保证。
  

但也因为有了签名B，我们在取公钥时，还需要先对证书里的签名B进行验证：

注意：解密证书里签名B所用的公钥也是由CA颁发的，它存在于CA证书里。

现在，我猜你已经能够记住证书的组成内容了：公钥+公钥的身份信息+它们的签名。

带着问题往下走：

Q1: 接收方从哪里获得这个CA证书呢？接收方又要如何验证这个CA证书的签名呢？似乎进入了无限循环♻️。

请接着往下看。

证书信任链

CA证书一般是在安装系统/软件时内置的，这样我们总该信任它了吧～

接下来，我们可以再了解一下证书的信任链。

根据证书在信任链中所处的位置，可以将证书分为三种：

• 根证书Root Certificate（参考Apple 操作系统中可用的受信任根证书[2]——Apple官方）
• 中间证书Intermediate Certificate
• 叶子证书Leaf Certificate
  

举例：我的开发者证书A（Apple Development）由中间证书B（Apple Worldwide Developer Relations Certification Authority，安装Xcode时内置）的CA签发，中间证书B由根证书C（Apple Root CA，系统内置）的CA签发，而根证书C是由自己的CA签发的，因为C已经在信任链的顶端啦，它自己说了算。

回到上一个问题：如何保证这个CA证书可信呢？只要接收方有签发方的证书，那么用证书里的公钥验证一下就可以了。比如一台iPhone安装我开发的App时，收到了我的开发者证书A，那么手机就会去找签发方的证书B（Apple Worldwide Developer Relations Certification Authority，iOS系统内置）来验证A是否可信。

现在，你也可以看看自己的Mac > 钥匙串Keychain软件 > 证书Certificates，加深理解。

继续带着问题往下走：

Q1: 加密公钥及其身份信息所用的CA私钥在我们的电脑本地吗？如果不是，该如何生成我们的证书呢？

iOS证书申请原理 & 申请方法

当然不是，这些私钥可是CA签发证书的秘密宝贝。比如，我们要想申请iOS开发者证书，则需要找Apple官方帮忙，Apple官方会使用上面提到的中间证书CA的私钥来签发证书。

申请原理

想要申请自己的iOS开发者证书，分为以下几步：

• 用自己的电脑生成公私钥对，并填写公私钥对的身份信息；
• 将公钥及其身份信息发送给Apple CA；
• CA使用使用哈希算法和CA私钥对数据（公钥及其身份信息）进行签名，数据和签名则组成了我们想要的证书；
• 我们再在CA上把证书下载到电脑上，安装证书后电脑会自动关联对应的私钥。
  

申请方式：2种

具体的申请方式有2种：1）上传CSR (CSR, Certificate Signing Request) 文件方式，2）Xcode自动申请方式，这里推荐第二种。

1）上传CSR文件方式

该方法适合想了解iOS证书申请原理的你。注意：该方式需要加入苹果开发者计划[3]，$99/年。

a) 打开Keychain > Certificate Assistant > Request a Certificate From a Certificate Authority...：

b) 输入身份信息（邮箱、证书名字），可以选择保存到本地，本地就得到了一个CSR (.certSigningRequest) 文件，里面包含了公钥及其身份信息。

你可能会问，那私钥放在哪里呢？如果你细心的话，你会发现Keychain > login > Keys里面已经多了一对你命名的公私钥对。

c) 登陆Apple Developer[4]网站，进入Certificates, Identifiers & Profiles板块，上传刚刚生成的CSR文件，即可生成证书（.cer文件），此时将证书下载到本地，双击即可导入Keychain，在Keychain > login > May Certificates中可以看到该证书。

如果你细心的话，你会发现Keychain里该证书已经和一把私钥绑定起来了，如果想把证书共享给其它开发者使用，则需要右键导出我们熟悉的.p12文件，它包含了证书和对应的私钥～

2）Xcode自动申请方式（推荐）

这种方式则不需要繁琐的上传CSR文件、下载.cer证书过程，也不会强求你加入Apple开发者计划。

a) 在Xcode里登陆Apple账号：Xcode > Preference > Account > Apple IDs > 「＋」。

b) 登陆片刻后，你就会发现KeyChain里自动多出一份相应的证书了。

注意：如果你加入了开发者计划，Apple开发者网站上也会自动添加该证书。

iOS签名 & 打包原理

终于来到iOS签名部分了，前面的内容你理解的怎么样呢？如果你还有点迷糊，那么记住签名的作用是防止传输的数据被篡改这一点，你就基本掌握本文的真谛了！

其实，在真正iOS签名的时候，还不是只附加证书（含公钥）这一个东西，我们还需要对证书做一层包装，那就是我们熟悉的Provisioning Profile文件，又叫PP文件、描述文件、供应配置文件。

PP文件

先来了解一下这个重要的PP文件，我们可以把它理解为证书的升级版。

如何生成

• 开发者平台上申请；
• Xcode自动生成：Xcode > Targets > Signing & Capabilities > 勾选Automatically manage signing。
  

文件结构

• App ID：
  
  • 在Apple开发者平台上注册；或者根据Xcode > Targets > Signing & Capabilities填写的Bundle ID自动生成。
  • 我们在Xcode > Targets > Signing & Capabilities中填写的Bunlde Identifier必须与App ID是一致或匹配的。
    
• Entitlements：
  
  • 允许使用的权限列表，实际在App中使用的权限必须是这个列表的子集，即我们在Xcode > Targets > Signing & Capabilities中添加的Capabilities，不能超出其范围。
  • 工程目录下也会有一份.entitlements文件（授权文件），它是根据Xcode > Targets > Signing & Capabilities里添加的Capabilities自动生成的。如果 App 中使用到了某项沙盒限制的功能，但是该.entitlements文件没有声明对应的权限，当App运行到相关代码时，App会直接 Crash。
    
• Certificates：由iOS开发者证书组成，可以不只一个，它们就是上面申请到的iOS证书。
• Devices：由iOS设备的UDID (Unique Device Identifier) 组成的列表，限定了可以开发调试该App的iOS设备。
• Signature：在生成PP文件时，由Apple CA对其进行签名，防止被人篡改。
  

示例

PP文件默认保存在：~/Library/MobileDevice/Provisioning\ Profiles。

下面是Xcode自动生成的一个PP文件预览：

签名 & 打包

iOS签名和打包过程其实是由Xcode来把控的，看下图：

• 首先，Xcode会检查App里的bundle ID是否匹配PP文件中的App ID，以及App里的Entitlements (.entitlements) 文件声明的权限是否在PP文件中Entitlements允许权限的范围内，二者任一条件为否，则检查不通过；
• 其次，Xcode会在电脑的Keychain里找，是否有匹配PP文件中Certificates的证书，如果匹配到了，才继续下一步；
• 然后，Xcode会检查匹配到的证书是否绑定了对应的私钥，如果没有，就无法进行下面的关键步骤——签名；
• 现在，开始利用哈希算法和私钥对App进行签名了；
• 最终，对App、PP文件和签名进行打包，即生成.ipa包。
  

⚠️：上面忽略了签名C和签名A的验证过程，在第1步使用PP文件之前和在第2步匹配到证书之后，都应先使用CA公钥对其附带的签名C和A进行验证，防止它们被篡改。如有错误，欢迎指正。

延伸问题：

Q1: Xcode会对App的哪些内容进行签名呢？

A1: 全部内容。但签名过程较为复杂，这里就不展开了，简而言之，为了权衡签名的安全性和效率，App的签名被分为4次哈希和1次加密，每次哈希都是环环相扣的，保证了App内容没有被篡改。

具体可参考细说iOS代码签名(三)：签名的过程及代码签名的数据结构[5]。

iOS验签原理

说完了iOS签名，那真机在安装App时如何验证它的签名呢？

首先，我们需要知道的是，App安装包分为测试包和正式包，两者的验签过程有所不同。

顺便补充一下测试包和正式包的知识：

1）测试包：分为内测包、准备上传App Store的发布包、Ad Hoc发布包、In-house企业内部发布包4种类型。

2）正式包：上传到App Store上的安装包。

⚠️：Xcode打的包都属于测试包。

参考iOS不同类型测试包介绍——搜狗测试公众号。

测试包

安装测试包时，真机对其进行了完整的验签过程，如下图所示：

• 首先，真机设备会使用系统内置的CA公钥验证PP文件及其签名C的合法性；
• 其次，真机再使用系统内置的CA公钥验证PP文件中证书及其签名A的合法性；（App里保存了生成签名B所用的证书信息，这样真机才知道去取出哪个证书里的公钥）
• 然后，真机再取出证书中的公钥验证App及其签名B的合法性；
• 最后，真机会检查自己的UDID是否在PP文件的Devices列表中，如果存在，才开始安装App。
  

⚠️：图里简化了验签的过程，相信你已经很熟悉这个过程了，哈希混淆、公钥解密、判等...

其实，签名的验证并非一次性完成，在安装、启动和运行时有着不同的校验规则，上面简化了该过程，具体可参考细说iOS代码签名(四)：签名校验、越狱、重签名[6]。

正式包

而安装正式包时，真机对其的验签过程简化了很多，因为对开发者证书的验签过程交给了App Store。

1）将发布包上传到App Store。

• 当你将发布包（测试包的一种）上传到App Store时，Apple官方同样会对发布包进行验签，其过程类似上述测试包的验签过程；
• 验签通过后，App Store会重新对App进行签名，这里用的就不是开发者证书对应的私钥了，而是CA 私钥；
• 最后，App Store只会对App和新的签名进行打包，生成.ipa包。（⚠️：不包含PP文件了）
  

2）真机设备安装正式包。

当设备从 App Store上下载 App 后，只需要用系统内置的CA公钥对App进行验签，验证通过即可安装。

练习一下

网上也有一些画得很好的图，你们可以按照序号回顾一遍过程，用来巩固本文的内容。

来自iOS证书那些事儿[7]——掘金。

来自iOS App 签名的原理[8]——Blog。

回到：本文目标

最后，我们再回到文章开头目标里提出的问题，解决那些问题之前永远铭记两个东西：包含私钥的证书（.p12 = .cer + private key）、PP文件（.mobileprovision）。

再看看我们的问题，只要找到上面两个东西就可以了：

• 如何在真机上跑自己的iOS项目，或者iOS开源库？
  
  • 包含私钥的证书：参考iOS证书申请方式那一节；
  • PP文件：在开发者平台上申请；或者由Xcode自动生成，Targets > Signing & Capabilities > 勾选Automatically manage signing。
    
• 如何在真机上跑公司的iOS项目？
  
  • 包含私钥的证书：向团队索要，注意文件后缀是.p12；
  • PP文件：向团队索要，记得让负责人在开发者平台上添加自己真机的UDID到PP文件中。
    

PS：

• 运行测试包安装的App时，一般还需要在真机上信任证书：Settings > General > VPN & Device Management。
• Xcode自动生成PP文件：
  

https://mp.weixin.qq.com/s?__biz=Mzg3MjcxNzUxOQ==&mid=2247484901&idx=1&sn=83fcf34b5b4b7a63c17742efa3ee20a8&chksm=ceea4845f99dc1537003bdebd2a93d09c9b413ad0cc8c5108cd93d5b84e63e65a30ce0f6c019&mpshare=1&scene=23&srcid=0513pnOkiCJ85oMFffRvTyc4&sharer_sharetime=1652596995747&sharer_shareid=dffa3b476cd51997aee9d7c92965a7c2#rd

Qter

AES加密算法1、明文拆分：AES算法在对明文加密的时候，并不是把整个明文一股脑加密成一整段密文，而是把明文拆分成一个个独立的明文块，每一个明文块长度128bit。
这些明文块经过AES加密器的复杂处理，生成一个个独立的密文块，这些密文块拼接在一起，就是最终的AES加密结果。

2、密钥长度：密钥是AES算法实现加密和解密的根本。对称加密算法之所以对称，是因为这类算法对明文的加密和解密需要使用同一个密钥。

AES支持三种长度的密钥：128位，192位，256位

平时大家所说的AES128，AES192，AES256，实际上就是指的AES算法对不同长度密钥的使用。数字越大表示加密轮数越多。

所以，AES128性能最好，AES256安全性最高。

3、填充：假如一段明文长度是192bit，如果按每128bit一个明文块来拆分的话，第二个明文块只有64bit，不足128bit。这时候怎么办呢？就需要对明文块进行填充（Padding）。

常见的填充方式有以下几种：
1）、NoPadding：不做任何填充，但是要求明文必须是16字节的整数倍。

2）、PKCS5Padding（默认）：如果明文块少于16个字节（128bit），在明文块末尾补足相应数量的字符，且每个字节的值等于缺少的字符数。

比如明文：{1,2,3,4,5,a,b,c,d,e},缺少6个字节，则补全为{1,2,3,4,5,a,b,c,d,e,6,6,6,6,6,6}

3）、ISO10126Padding：如果明文块少于16个字节（128bit），在明文块末尾补足相应数量的字节，最后一个字符值等于缺少的字符数，其他字符填充随机数。

比如明文：{1,2,3,4,5,a,b,c,d,e},缺少6个字节，则可能补全为{1,2,3,4,5,a,b,c,d,e,5,c,3,G,$,6}

值得注意的是，加密时使用了某种填充方式，那么解密时也必须使用同种填充方式。

4、加密过程：
1）把明文按照128bit拆分成若干个明文块。

2）按照选择的填充方式来填充最后一个明文块。

3）每一个明文块利用AES加密器和密钥，加密成密文块。

4）拼接所有的密文块，成为最终的密文结果

5、AES加密器：

加密轮数分为：
初始轮（Initial Round）：1次
普通轮（Rounds）： N次
最终轮（Final Round）： 1次

除去初始轮，各种Key长度对应的轮数如下：

AES128：10轮

AES192：12轮

AES256：14轮

初始轮只有一个步骤：

——加轮密钥（AddRoundKey）

普通轮有四个步骤：

——字节代替（SubBytes）

——行移位（ShiftRows）

——列混淆（MixColumns）

——加轮密钥（AddRoundKey）

最终轮有三个步骤：

——字节代替（SubBytes）

——行移位（ShiftRows）

——加轮密钥（AddRoundKey）

即最终轮相比普通轮少了列混淆。

6、加密步骤的具体含义：

1）字节替代（SubBytes）：

16字节（128bit）的明文块在每一个处理步骤中都被排列成4X4的二维数组。

所谓字节替代，就是把明文块的每一个字节都替代成另外一个字节。替代的依据是什么呢？依据一个被称为S盒（Subtitution Box）的16X16大小的二维常量数组。

假设明文块当中a[2,2] = 5B（一个字节是两位16进制）（1bit是一位二进制数），那么输出值b[2,2] = S[5][11]。

即根据字节内容的4X4数组 对应S盒中的数据 转换为另一个4X4数组。

2）行移位（ShiftRows）

如图所示，
第一行不变，
第二行整体左移 1 个字节，
第三行整体左移 2 个字节，
第四行整体左移 3 个字节

即第 x 行整体左移 x-1 个字节，最左边的移动到最右。

3）列混淆（MixColumns）

这一步，输入数组的每一列要和一个名为修补矩阵（fixed matrix）的二维常量数组做矩阵相乘，得到对应的输出列。

4）加轮密钥（AddRoundKey）：

这一步是唯一利用到密钥的一步，128bit的密钥也同样被排列成4X4的矩阵。

让输入数组的每一个字节a[i,j]与密钥对应位置的字节k[i,j]异或一次，就生成了输出值b[i,j]。

需要补充一点，加密的每一轮所用到的密钥并不是相同的。这里涉及到一个概念：扩展密钥（KeyExpansions）。

5）扩展密钥（KeyExpansions）：

AES源代码中用长度 4 * 4 *（10+1） 字节的数组W来存储所有轮的密钥。W{0-15}的值（16字节，128bit）等同于原始密钥的值，用于为初始轮做处理。

后续每一个元素W都是由W[i-4]和W[i-1]计算而来（W[16] = W[12] 运算 W[15]），直到数组W的所有元素都赋值完成。

W数组当中，W{0-15}用于初始轮的处理，
W{16-31}用于第1轮的处理（以16字节为单位），
W{32-47}用于第2轮的处理 …
一直到W{160-175}用于最终轮（第10轮）的处理。

6）解密过程：
解密过程就是把加密过程倒置过来，
最终轮->普通轮->初始轮。
扩展密钥W[x]的使用顺序和加密相反

7、加密模式：

AES的工作模式，体现在把明文块加密成密文块的处理过程中。AES加密算法提供了五种不同的工作模式：
1）ECB模式（默认）：
电码本模式 Electronic Codebook Book

2）CBC模式：
密码分组链接模式 Cipher Block Chaining

3）CTR模式：
计算器模式 Counter

4）CFB模式：
密码反馈模式 Cipher FeedBack

5）OFB模式：
输出反馈模式 Output FeedBack

注意：加解密需要使用同一种加密模式。

8、加密模式详解：

1）ECB模式（Electronic Codebook Book）是最简单的工作模式，在该模式下，每一个明文块的加密都是完全独立，互不干涉的

优点：
1.简单
2.有利于并行计算

缺点：
相同的明文块经过加密会变成相同的密文块，因此安全性较差。

2）CBC模式（Cipher Block Chaining）引入了一个新的概念：初始向量IV（Initialization Vector）。
IV的作用和MD5的“加盐”有些类似，目的是防止同样的明文块始终加密成同样的密文块。

从图中可以看出，CBC模式在每一个明文块加密前会让明文块和一个值先做异或操作。IV作为初始化变量，参与第一个明文块的异或，后续的每一个明文块和它前一个明文块所加密出的密文块相异或。
这样一来，相同的明文块加密出的密文块显然是不一样的。

优点：
安全性更高

缺点：
1.无法并行计算，性能上不如ECB
2.引入初始化向量IV，增加复杂度。

3)计算器模式（Counter (CTR)）

计算器模式不常见，在CTR模式中， 有一个自增的算子，这个算子用密钥加密之后的输出 和 明文异或 的结果得到密文，相当于一次一密。这种加密方式简单快速，安全可靠，而且可以并行加密，但是 在计算器不能维持很长的情况下，密钥只能使用一次 。CTR的示意图如下所示：
Plaintext：明文
Ciphertext：密文
Encrypt：加密

即与CBC不同的是，将初始向量IV变为了自增算子，自增算子和加密密钥进行加密组合，使密钥变化，再将变化后的密钥与明文（Plaintext）异或，得到密文块。

优点：
简单快速，安全可靠
利于并行计算

缺点：
在计算器不能维持很长的情况下，密钥只能使用一次

4）CFB模式：全称Cipher FeedBack模式（密文反馈模式）。在CFB模式中，前一个密文分组会被送回到密码算法的输入端。所谓反馈，这里指的就是返回输入端的意思。

在ECB模式和CBC模式中，明文分组都是通过密码算法进行加密的，然而，在CFB模式中，明文分组并没有通过密码算法来直接进行加密。

明文分组和密文分组之间并没有经过“加密”这一步骤。在CFB模式中，明文分组和密文分组之间只有一个XOR。

CBC和CFB的区别：

在生成第一个密文分组时，由于不存在前一个输出的数据，因此需要使用初始化向量（IV）来代替。一般来说，我们需要在每次加密时生成一个不同的随机比特序列用作初始化向量。

5）OFB模式（输出反馈模式Output FeedBack ）：
在OFB模式中，密码算法的输出会反馈到密码算法的输入中。
OFB模式不是通过密码算法对明文直接加密的，而是通过将“明文分组”和“密码算法的输出”进行XOR来产生“密文分组”的。

OFB模式和CFB模式的区别仅仅在于密码算法的输入。
CFB模式中，密码算法的输入是前一个密文分组，也就是将密文分组反馈到密码算法中，因此有了“密文反馈算法”这个名字。
OFB模式中，密码算法的输入则是密码算法前一个输出，也就是将输出反馈给密码算法，因此就有了“输出反馈模式”这个名字。

CFB模式和OFB模式对比图：

CFB模式中是对密文分组进行反馈，因此必须从第一个明文分组开始按顺序进行加密，也就是说无法跳过明文分组1而先对明文分组2进行加密。

OFB模式中，XOR所需要的比特序列（密钥流）可以事先通过密码算法生成，和明文分组无关。只要提前准备好所需的密钥流，则在实际从明文生成密文的过程中，就完全不需要动用密码算法了，只要将明文与密钥流进行XOR就可以了。和AES等密码算法相比，XOR运算是非常快的。这就意味着只要提前准备好密钥流就可以快速完成加密。换个角度来看，生成密钥流的操作和进行XOR运算的操作是可以并行的。
————————————————
版权声明：本文为CSDN博主「旋转的Kumamon」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_42843172/article/details/112544479