前言
算法类型定义算法加密的数学实现（如明文块的长度，如何对明文密文进行加解密），算法模式则定义具体类型中加密的流程细节（例如加密的轮数、如何操作加解密的输入输出）。
对称算法根据明文的加密方式分成了流算法和分组算法。
- 流算法一次加密明文中的一个位，解密也是按位解密的。主要的有祖冲之算法和SNOW3G算法，主要用于5G场景，由于5G场景中空口带宽比较珍贵，计算粒度到位。
- 分组算法一次加密明文中的一个块，不同的算法块长度可以不一样，具体可以体现在算法的名称中，如AES-128-CBC。
算法模式
对于分组算法，如果直接对明文块进行加密，如果不同的块内容一样，会导致加密出来的密文也都是一样的，比较容易被破译。为了处理这种问题，就引入了算法模式，给不同块的输入增加一些盐值，这样即使块的内容一样，由于盐值不一样，加密出的密文也会不一样。不同的算法模式，根据盐值如何产生，及模块加密的流程分为了ECB、CBC、CFB、OFB、CTR模式。
电子编码簿（ECB）模式
ECB模式是最简单的模式，也是最基础的模式。ECB模式没有盐值，直接将明文消息分成64位块，然后单独加密每个块。所有的块使用相同的密钥进行加密。如果原文中有多个相同的明文块，那么也会产生多个相同的密文块。
这种模式适合那些短消息加密，明文重复概率比较小。
加密块链接（CBC）模式
CBC模式为了解决ECB模式的相同明文块加密得到相同密文块的问题。通过使用反馈的形式，把上一块的加密结果反馈到当前块的加密中，当前块的加密跟前面所有块的加密结果都相关，这样就可以使得相同明文块加密得到不同的密文块。第一个明文块则跟一个随机的文本（初始向量）相关,第一个密文块作为第二个明文块的初始向量，以此类推。
CBC模式下加密有三个重要的相关项： 初始向量、密钥、明文消息。每个块的初始向量不一样，但是加密的密钥是一样的。
加密反馈（CFB）模式
前面两种模式都是按块加密的，但不是所有的应用都适用块加密。这时候就使用流加密或者CFB模式了，CFB模式加密数据可以使用更小的单元，比如8位，小于块的长度（64位）。
CFB模式一次处理8位，流程相对前面两种更复杂一些。
1、CFB模式也采用64位的初始化向量，通过加密方式得到加密后的向量。
2、加密后的向量的前j位和明文异或，产生j为密文C，把C发送给接收方。
3、加密后的向量左移j位，并把第二步得到的C填充到最右边的j位。
4、重复1-3步，一直到加密完所有的明文数据。
输出反馈（OFB）模式
OFB模式跟CFB模式很像，CFB模式是把密文填入下一个阶段的向量低8位，而OFB是把向量加密的结果填入下一阶段的向量低8位。这样一来，OFB的加密结果跟前一个明文无关，跟IV相关。而CFB的加密结果跟前一个明文和IV都是相关的。
计数器(CTR)模式
CTR模式各个块的IV采用一个计数器值，计数加密之后再和明文异或得到密文。计数块的大小等于明文块的大小。
CTR模式可以并行地计算多个块，因为输入跟前面的明文没有什么关系。
更多
加密模式还有一种xts，具体带学习后再小结。模式比较多，又很相似，刚开始看很容易混淆，后面慢慢地熟悉了就好了吧。
更多1
今年小组扩张的比较猛，从年初的5人扩充到了14人。人多了，就有很多人比较闲。后面招的基本都是应届生或者工作三年以下的，应届生就不用说了，基本等于白纸。工作几年的那几个呢，我感觉都不是技术爱好者，仅仅是工作糊口而已。
人多了，问题也就多了。当然，这些问题主要还是因为大家没有很强的责任心导致的。联调一个功能，遇到问题了，不去积极解决问题，而是在互相推诿。A和B联调，A遇到问题了，首先自身没有深入定位，直接就去找B了。而B呢，直接说代码不是他写的，他没有改过，让找C。C又是说代码已经移交个B，又让找B。真的好扯，都是一个组的，代码就在那，都不愿意自己gdb去看看，总想着推脱责任，好无语。
另外，很多工作并没有比较明确的时间点，有些也没有明确的目标，大家都在磨洋工啊。技术不好的也不想着提升技术，团队就是个散沙，然后有事情了又是拉几个老员工顶上去。呵呵。
行动，才不会被动!
欢迎关注个人公众号 微信 -> 搜索 -> fishmwei，沟通交流。
博客地址： https://fishmwei.github.io
掘金主页： https://juejin.cn/user/2084329776486919