【密码算法之八】GCM实战：从原理到TLS 1.3中的应用

最新推荐文章于 2026-06-22 12:15:06 发布

原创

最新推荐文章于 2026-06-22 12:15:06 发布 · 193 阅读

1. 从“锁”到“封条”：为什么我们需要GCM？

聊到加密，很多朋友的第一反应可能就是“把内容变成乱码，别人看不懂”。这没错，但只做了一半。想象一下，你给朋友寄一个上锁的保险箱（加密），但运输途中有人偷偷把整个箱子调包了，或者往里面塞了张假纸条。你的朋友能打开锁，但他怎么知道里面的东西是不是你放的原件，或者箱子本身有没有被动过手脚呢？

这就是传统加密模式（比如我之前聊过的ECB、CBC、CTR）的短板：它们只管“保密”，不管“防篡改”。在网络安全里，这叫做缺乏“消息认证”。攻击者虽然看不懂密文，但他可以截获、复制、调换或者重放你的数据包，接收方解密后可能得到一堆垃圾信息，甚至被引导执行危险操作。

所以，现代安全通信需要一个“既上锁又贴封条”的方案。锁负责保密（加密），封条负责证明完整性和来源（认证）。GCM（Galois/Counter Mode，伽罗瓦/计数器模式）就是这样一个把两件事漂亮地打包在一起的算法。它本质上是一个“认证加密”（Authenticated Encryption）模式，一次操作，同时输出密文和一个叫做“认证标签”（Authentication Tag）的封条。接收方拿到后，先用密钥验证“封条”是否完好，如果完好，再解密；如果封条被破坏，直接丢弃数据，根本不用费劲去解密。

为什么GCM能脱颖而出，成为TLS 1.3等现代协议的首选？因为它不仅安全，而且快。它的核心是两个高效组件的结合：GCTR（基于CTR模式的加密流）负责高速加密，GHASH（在伽罗瓦域上计算的哈希）负责高速生成认证标签。这种设计特别适合当今需要处理海量、低延迟网络流量的场景，比如你的每一次HTTPS网页访问、每一次手机App与服务器的通信。

2. 拆解GCM的双引擎：GCTR与GHASH如何协同工作

要理解GCM为什么又快又稳，就得钻进它的引擎盖看看。别担心，我们不用深究复杂的数学证明，用比喻和流程把它讲明白。

2.1 加密引擎：GCTR（伽罗瓦计数器模式）

GCTR是GCM的加密部分，它脱胎于我之前讲过的CTR模式。CTR模式的核心思想是“用密钥和计数器生成一个伪随机的密钥流，然后像一次性密码本那样与明文进行异或运算”。GCTR继承了这个思想，并做了一些规整化。

它的工作步骤可以这样理解：

准备计数器：从一个初始计数器（叫做ICB或J0）开始。在GCM里，这个初始值通常由Nonce（一个只用一次的随机数）衍生而来。
生成密钥流：把计数器值（CB1, CB2, CB3...）用底层的分组密码（比如AES）加密。注意，这里加密的不是你的数据，而是计数器本身。加密后得到的就是一段段密钥流块。
异或加密：将这些密钥流块与你的明文数据块一一进行异或（XOR）运算，直接得到密文。对于最后一块不满128比特的数据，只取密钥流对应长度的部分进行异或。

# 一个非常简化的GCTR加密概念演示（非生产代码）
def gctr_encrypt(key, plaintext, initial_counter):
    ciphertext = b""
    counter = initial_counter
    # 将明文按128比特（16字节）分块
    for i in range(0, len(plaintext), 16):
        block = plaintext[i:i+16]
        # 加密当前计数器值，得到密钥流块
        keystream_block = aes_encrypt(key, counter)
        # 明文块与密钥流块异或
        encrypted_block = bytes(a ^ b for a, b in zip(block, keystream_block))
        ciphertext += encrypted_block
        # 计数器递增（GCM有特定的递增规则inc32）
        counter = increment_counter(counter)
    return ciphertext

GCTR的优势非常明显：并行化。因为每个计数器的加密都是独立的，所以可以同时处理多个数据块，充分利用现代CPU的多核能力，加密速度飞快。同时，它不需要像CBC模式那样依赖上一块的密文，避免了错误传播。