📚 课程目录第2章加密开销的定义

二、加密开销的定义：计算、存储、带宽、能耗

你好，我是负责这门课的工程师。今天我们来拆解加密开销到底指什么。说实话，很多人在做系统设计时，只盯着算法的安全性级别，却忽略了它带来的成本。我自己就吃过这个亏——当年在低功耗传感器上硬上完整TLS握手，结果电池三天就烧干了。

加密开销不是单一指标，它至少包含四个维度：计算、存储、带宽、能耗。你设计的系统每多一层加密，这四个维度就会同步增加。咱们一个个讲清楚。

2.1 计算开销：CPU 为你买单

计算开销是指加密/解密操作消耗的处理器资源。说白了，就是算法需要多少条指令、多少时钟周期。我常用的度量方式有两种：

吞吐量：单位时间能处理的数据量（如 MB/s）。
延迟：单个操作从开始到结束的时间（如 µs）。

举个具体的例子。在我之前的一个项目中，我们对AES-128-GCM做了基准测试：在2.0 GHz ARM Cortex-A72上，达到了约 2.3 MB/s 的加密速度。这个数据看起来还行，但当带宽需求升到 50 MB/s 时，CPU 就被吃光了。那你必须考虑硬件加速或降低密钥粒度。

小提示： 测量时记得关掉 Turbo Boost / DVFS，否则测得的是“带魔力的数字”，上线就露馅。

下面的伪代码演示了如何用 clock_gettime 粗略测量单次加密耗时——你可以在嵌入式环境中直接跑。

#include <time.h>

void measure_aes(const uint8_t *plain, const uint8_t *key) {
    struct timespec start, end;
    clock_gettime(CLOCK_MONOTONIC, &start);

    // 假设调用 AES 加密函数
    aes_encrypt(plain, key, cipher);

    clock_gettime(CLOCK_MONOTONIC, &end);
    double elapsed = (end.tv_sec - start.tv_sec) * 1e9 +
                     (end.tv_nsec - start.tv_nsec);
    printf("single AES encrypt: %.2f ns\n", elapsed);
}

2.2 存储开销：密钥和证书比你想象的重

很多人忽略存储开销，以为密钥就几十个字节。但你想想看，一个完整的 PKI 系统要存的东西可不少：

私钥（RSA-4096 约 2 KB）
证书链（往往几十 KB）
会话票据（如果使用 TLS 恢复）
密钥派生中间状态

我记得有一次帮客户做固件升级加密，他们想把 2048 位的 RSA 私钥连同固件镜像一起塞进 32 KB 的 Flash 里。结果光是密钥和证书就占了 10 KB，剩下的空间连升级包都放不下了。后来不得不拆成多个小密钥分段更新——这就是密钥边界粒度对存储的直接冲击。

  关键结论： 存储开销 = 固件/证书占用的 Flash 或 RAM 空间。在 IoT 设备上，这是硬约束。

2.3 带宽开销：每一次握手都要付“过路费”

带宽开销主要来自两方面：协议握手时的额外数据量 和 加密数据本身的大小膨胀。例如：

TLS 1.3 handshake：约 2~3 KB 的轨迹（ClientHello + ServerHello + Cert + Finished）。
AES-GCM 会附加 16 字节的认证标签，这对于小包（如 MQTT 传感器数据，有效载荷 32 字节）来说膨胀率高达 50%。

我曾经在一个 LoRa 链路上做端到端加密，每个包最大 256 字节。你想想看，如果加了 16 字节 HMAC 和 8 字节序号，有效载荷只剩 232 字节。再考虑重传，带宽开销直接翻倍。这种情况下，你就得思考：能不能用更短的标签（比如 8 字节）并承担稍高的误报风险？这就是加密开销与安全边界的权衡。

2.4 能耗开销：电池的无声杀手

能耗开销往往是最隐蔽的。计算、存储、带宽最终都会转化为能量消耗。我习惯把能耗拆成两部分：

计算能耗：每百万次加密操作需要的焦耳数。
通信能耗：发送/接收加密数据时射频消耗的能量（通常比计算能耗高一个数量级）。

举个例子：AES-128 在低功耗 MCU 上大约消耗 0.2 µJ/byte 的计算能量；而通过 LoRa 发送一个 256 字节的包需要约 100 mJ（发射电流 30 mA，持续 0.3 s，电压 3.3V）。你看，通信能耗是计算能耗的 500 倍。所以如果你的加密协议增加了数据包长度，电池会直接抗议。

避坑指南： 我曾经在电池供电的传感器上使用 ECDSA 签名（约 5 MB/s 的吞吐量），结果每次签名需要 80 ms。而对于每 10 秒上报一次的场景，CPU 有 0.8% 的时间被加密吃掉，看似不多——但加上射频链路，整体占空比高了 30%。后来我将签名改为 HMAC（对称方案），电池寿命从 3 个月延长到了 11 个月。别迷信非对称，要算总账。

四维开销的关系图

下方 SVG 展示了四个维度之间的关联：计算、存储、带宽、能耗互相牵动，没有独立变量。

四维开销对比表

下面这张表总结了每个维度的典型关注点、常用度量单位以及在我项目中的实际观察：

开销维度	典型度量	常见瓶颈场景	我的经验值
计算	吞吐量 (MB/s)、延迟 (µs)	实时系统，高数据率链路	2 GHz 上 AES 约 2.3 MB/s，容易成为瓶颈
存储	Flash 占用 (KB)、RAM 临时缓冲	IoT 固件升级，证书链管理	一次 2048 位 RSA 私钥 + 证书吃掉 10 KB
带宽	额外字节/包、膨胀率 (%)	低带宽网络（LoRa、BLE）	256 字节包加 16 字节标签，膨胀 6.25%
能耗	每操作能量 (µJ)、电池寿命	电池设备，数据中心电力成本	通信能耗是计算能耗的 500 倍

为什么要同时衡量这四个维度？

你想想看，一个加密方案在桌面服务器上可能完美，但到了嵌入式设备就完全无法工作。原因就是四个开销维度的权重变了。我在设计边缘安关时，曾经只优化计算吞吐，结果存储预算超标，被迫裁掉原有的证书吊销列表——这就是典型的“打过补丁忘了窗户”。

关键思路： 每个维度都有一个“最短板”。你的系统只要能满足最差的那个维度的限制，其他维度可以适当退让。比如，如果存储是硬约束，那就优先选择密钥短的算法（如 ECC 而不是 RSA），即使计算开销稍高也没关系。

  我建议你在项目初期就建立一张四维开销表： 列出目标设备的 CPU 指令数上限、Flash/RAM 上限、每次交互的最大报文长度、以及电池容量。然后再反推选择哪个加密方案、密钥边界应该划分多细。这个动作能帮你规避 80% 的后期返工。

好，以上是加密开销的四个维度。记住，定义清楚开销是做任何权衡的第一步。没有度量，就没有管理。