如果给一张有清晰轮廓的位图加密，用 ECB 模式处理之后，加密结果仍然能看出原来的轮廓——只是颜色变得杂乱。这张被称为「ECB 企鹅图」的示意图在密码学教材里出现了二十多年，它用一个直观的例子说明了 ECB 的根本问题：加密之后，数据的结构特征被完整保留了下来。
问题出在「每块独立」
ECB（Electronic Codebook，电子密码本）的做法最直接：把明文按 16 字节切成块，每个块单独用 AES 加密，块与块之间没有任何关联。
这个设计带来了一个不可避免的后果：相同的明文块，必然得到相同的密文块。
因为每个块的加密过程完全由「密钥 + 明文块」决定，没有任何来自其他块的信息参与。密钥固定，明文块相同，输出当然相同。
这个性质在密码学上叫「确定性加密」，它在某些场景下是需要的，但在加密大量数据时就成了缺陷——因为数据的重复模式会被暴露。
重复模式泄露了什么
位图的例子最直观。图片里大片同色的区域会产生大量相同的明文块，加密后变成大量相同的密文块，于是色块的边界被保留，轮廓依然可见。
同样的道理适用于其他数据。如果加密的是数据库导出文件，某几列取值重复度高，密文里就会出现规律性的重复片段，攻击者可以通过统计这些片段的分布推断出很多信息。
如果是结构化文本，问题更明显。比如一批 JSON 记录，每条都有相同的字段名。这些字段名在明文里重复出现，加密后在密文里也重复出现，攻击者一眼就能看出记录的边界和字段的位置。
一个具体的对比
假设明文是 32 字节，由两个相同的 16 字节块组成：AAAA...A 重复两遍。
用 ECB 加密，两个块得到相同的密文，输出的 32 字节是「密文X + 密文X」。攻击者不需要解密就能看出「这两段内容相同」。
用 CBC 加密，第一个块与前一块密文异或，第二个块与第一个块的密文异或，两个块的输入不同，输出也不同。攻击者看到的是两段不同的密文，无法判断原文是否重复。
这个对比说明了模式的核心作用：打破明文与密文之间的对应关系，让相同的明文在不同的位置产生不同的密文。
为什么还有 ECB 的选项
既然问题这么明显，为什么很多工具还提供 ECB？
主要有两个原因。一是历史兼容——一些早期系统和协议用 ECB 加密，为了互通不得不保留支持。二是教学演示——ECB 的逻辑最简单，适合用来解释分组密码的基本工作原理，也方便观察模式的影响。
还有一个不太合理但确实存在的原因：ECB 不需要 IV。其他模式都要处理 IV 的生成和传递，ECB 省掉了这一步，实现起来最简单。有些开发者为了图省事选择了 ECB，而没有意识到代价。
该用什么替代
如果需要「相同明文产生相同密文」以便做等值查询（例如加密后仍然能按密文检索），直接使用 ECB 是不安全的。正确的方案是使用确定性加密的专门构造，例如在固定 IV 的前提下使用 CBC，或者采用专门的保序/保格式加密方案。这类方案的设计目标是可控地暴露有限信息，而不是无差别地暴露所有重复模式。
如果只是普通的数据加密，那么选择很明确：用 CBC 并配合随机 IV，或者更好——使用带认证的模式如 GCM，它同时提供机密性和完整性校验。
判断标准很简单：只要加密的数据超过 16 字节，就不应该用 ECB。只有在加密单个独立分组、且不关心重复性泄露的极少数场景下，ECB 才勉强可用。
检查清单
- ECB 对每个 16 字节块独立加密，相同明文块必然产生相同密文块
- 重复模式会被保留，攻击者可以从密文推断出数据结构
- 位图加密后仍能看出轮廓，是这个问题最直观的演示
- 保留 ECB 主要是为了历史兼容与教学演示，不是因为安全
- 需要等值查询时应使用专门的确定性加密方案，而非直接上 ECB
- 超过 16 字节的数据加密应使用 CBC 配合随机 IV，或带认证的 GCM