## AES-G header CM 中的 GCM 签名算法

GCM（Galois/Counter Mode）是指使用Counter模式和GMAC消息认证码的对称加密。

ECB（Electronic Mode电子码本模式）

当我们有一段明文并需要使用 AES 对其进行加密时，我们需要对明文进行分组。 组长度可以是 128、256 或 512 位。 采用ECB模式的分组密码算法的加密过程如下：

从上图可以看出，明文中的重复排列会在密文中得到体现。

而且，当密文被篡改时，解密后对应的明文分组也会出现错误，解密者不会注意到密文被篡改。 换句话说，ECB无法提供密文的完整性验证。

因此，任何情况下都不推荐使用ECB模式。

CTR（计数器模式）

在计数器模式下，我们不再对密文进行加密，而是加密一个逐次累加的计数器，利用加密后的比特序列与明文组进行异或得到密文。 流程如下：

在计数器模式下，每次与明文组异或的比特序列都不同。 因此，计数器模式解决了ECB模式中相同明文得到相同密文的问题。 CBC、CFB、OFB模式都可以解决这个问题，但是CTR的另外两个优点是：1）支持加密和解密的并行计算，可以提前为加密和解密做好准备； 2) 错误密文中的对应位只会影响明文中的位。 相应位等优点。

但CTR仍然无法提供密文消息完整性验证的功能。

有人可能会认为，如果将密文的哈希值与密文一起发送，密文接收方计算收到的密文的哈希值，并与收到的哈希值进行比较，这样就可以验证了。 消息的完整性怎么样？

如果你仔细想一想，就能发现这其中的漏洞。 当篡改者拦截到原始密文消息时，他首先对密文进行篡改，然后计算篡改后的密文哈希值，并替换原始消息中的密文哈希值。 这样，消息接收方仍然没有办法检测到源密文的篡改。 可见，使用单向哈希函数计算哈希值仍然不能解决消息完整性验证的问题。

MAC（Message Authentication Code，消息验证码）

为了验证消息的完整性，必须引入另一个概念：消息验证码。 消息认证码是与秘密密钥相关联的单个散列函数。

密文的双重发送和接收需要事先共享密钥。 密文发送方将密文的MAC值随密文一起发送，密文接收方通过共享密钥计算接收到的密文的MAC值，从而可以验证接收到的密文的完整性。 当篡改者修改密文时，如果没有共享密钥，则无法计算出被篡改密文的MAC值。

如果生成密文的加密模式是CTR，或者其他带有初始IV的加密模式，不要忘记使用初始定时器或初始化向量值作为附加消息来与密文一起计算MAC。

GMAC（伽罗瓦消息验证码模式，伽罗瓦消息验证码）

对应上图中的消息认证码，GMAC使用Galois Field（GF，有限域）乘法来计算消息的MAC值。 假设密钥长度为128位。 当密文大于128位时，需要按128位对密文进行分组。 申请流程如下：

GCM（伽罗瓦/计数器模式）

GCM中的G指的是GMAC，C指的是CTR。

GCM可以提供消息的加密和完整性验证。 此外，它还可以提供附加消息的完整性验证。 在实际应用场景中，有一些信息我们不需要保密，但信息的接收者需要确认其真实性，比如源IP、源端口、目的IP、IV等。因此，我们可以添加这部分作为计算 MAC 值的附加消息。 下图中的Ek表示使用对称密钥k对输入进行AES运算。 最后，密文接收方将收到密文、IV（计数器CTR初始值）和MAC值。