前言
如果我们的编写app上架Google应用市场，可能收到Google关于加密模式的整改通知："Unsafe Cipher Mode.Your app contains a less secure encryption mode."相应的整改建议如下图
下面我们来看看什么是分组加密以及常用的分组加密模式。
分组密码
AES和DES都是分组密码。所谓分组密码，将明文消息经过二进制编码后的序列分割为固定长度的组，用同一秘钥和算法对每一组加密。且密文、明文等长。
DES算法的密钥长度是56Bit，因此算法的理论安全强度是2的56次方。现在的安全编码规范中已经不推荐使用DES（3DES）了。
AES的分组密码为128bits，支持三种密码标准：128bits，192bits，256bits。
分组加密模式
ECB
如图所示，ECB模式下，相同的明文加密后会得到相同的密文。从攻击者的角度看，通过观察密文，就可以知道明文存在怎样的重复组合，并可以以此为线索来破译密码，因此ECB模式存在一定风险，在做数据强保护时不推荐使用。
CBC
CBC模式即密文分组链接模式，密文分组像链条一样相互连接在一起。前一个密文分组参与当前明文分组的加密运算，这样就解决了ECB模式相同明文加密所得密文相同的缺陷。
但第一个明文分组加密时没有前置的密文分组，怎么办呢？这里引入IV的概念，使用IV代替前置的密文分组。
初始化向量（IV）全称Initialization Vector。一个长度为一个分组的比特序列来代替“前一个密文分组”，这个比特序列称为初始化向量（Initialization Vector），通常缩写为IV，一般来说，每次加密时都会随机产生一个不同的比特序列来作为初始化向量。
CFB
CFB模式即密文反馈模式，将前一个密文分组送回到密码算法的输入端。
在ECB模式和CBC模式中，明文分组都是通过密码算法进行加密的，然而，在CFB模式中，明文分组并没有通过密码算法来直接进行加密，明文分组和密文分组之间只有一个XOR操作。
不能抵御重放攻击。
发送人连续使用相同密钥发送密文，攻击者可以使用旧数据包替换新数据包或者可以将新发送密文的后部分分组替换为旧密文的后部分分组（混入）该场景下，替换包前面的数据包相同。导致接收人收到的消息重复，且无法正确判断是通信错误还是人为攻击。
OFB
OFB模式即输出反馈模式。密码算法的输出会反馈到密码算法的输入中，密文分组不在参与加密循环。
CFB和OFB方式很相似，这里明确一下他们之间的区别，反馈的内容不同：
- CFB（密文反馈模式）模式中，密码算法的输入是前一个密文分组，也就是将密文分组反馈到密码算法中，因此有了“密文反馈算法”这个名字。
- OFB（输出反馈模式）模式中，密码算法的输入则是密码算法前一个输出，也就是将输出反馈给密码算法，因此就有了“输出反馈模式”这个名字。
CTR
CTR模式即计数器模式，每个分组对应一个逐次累加的计数器，并通过对计数器进行加密来生成密钥流。使用密匙流XOR明文分组来生成密文分组。
如何应对google的整改通知
通过上面的分析，我们看到ECB的加密模式确实不安全，如想通过google的整改要求可以这么做：
- 使用上面表格中推荐的加密模式，或者按照google整个要求中推荐的加密模式。
- 如果服务端实在不方便调整加密模式（跨部门，没办法_），可以使用临时方案。将"AES/ECB/NoPadding"进行加密，在初始化时解密还原。因为google是使用静态扫描的方式发现加密模式不合规的，使用该方法可临时上架。
