3. 密码算法在低功耗设备上的性能瓶颈

在低功耗设备上谈密码性能，不能只看“加密一次要多少毫秒”。同一颗 MCU 上，AES-128 的加解密可能只占几十微秒，但一次 TLS 握手、一次固件签名验证或一次密钥协商，往往会把计算、存储、通信和能耗四条约束同时推到极限。理解瓶颈的关键，是把密码运算放回真实的数据通路中，看它在哪里消耗时间、占用内存、触发无线收发，并最终折算成电池寿命。

四类瓶颈不是并列的，而是相互转化的

计算瓶颈表现为 CPU 周期数。以常见的 Cortex-M0+（无硬件 AES 加速、24 MHz）为例，纯软件 AES-128 加密 16 字节分组大约需要 1500～3000 个周期，即约 60～125 μs/块。若一次传输 256 字节，仅 AES 加密就约 1～2 ms。若换成 Cortex-M4 带 AES 指令扩展，同样数据可降到约 200～400 周期/块，差距接近一个数量级。这说明“算法是否重”必须结合目标核的指令能力判断。

存储瓶颈常被低估。对称加密本身状态很小，但公钥算法和协议栈会显著抬高 RAM 与 Flash 需求。例如 ECC P-256 的标量乘法在软件实现中需要保存多个 256 位中间点，峰值 RAM 可达 2～6 KB；RSA-2048 私钥运算若使用 CRT，临时大数缓冲区可能超过 8 KB。对于只有 8～20 KB RAM 的 BLE SoC，这足以决定能否同时运行协议栈和应用任务。Flash 侧则受算法库、曲线参数、证书链和根证书影响，常增加 20～80 KB。

通信瓶颈与密码并非独立。加密后的数据长度、握手往返次数、证书链大小都会改变射频开启时长。射频通常是低功耗设备中瞬时功耗最高的模块：BLE 收发峰值约 5～15 mA，Sub-GHz 或 Wi-Fi 可到 100 mA 以上。一次多一个握手往返，可能多出数毫秒到数十毫秒的射频窗口，其能耗远高于同时间内 CPU 做 AES 的能耗。

能耗瓶颈是前三者的积分结果。粗略估算可用：

E ≈ P_cpu × t_cpu + P_radio × t_radio + P_sleep × t_sleep

其中 t_cpu 由计算量决定，t_radio 由通信轮次和包长决定，t_sleep 是剩余时间。若某设备用 CR2032（约 220 mAh）供电，平均电流 20 μA 可运行约一年；若每次唤醒多消耗 1 mJ，按每天 100 次计算，一年额外约 36.5 J，折合到 3 V 约 3.4 mAh，看似不大，但若每天 1000 次、每次多 10 mJ，就会额外消耗约 340 mAh，直接超过电池容量。因此瓶颈分析必须落到“每次事务的能耗预算”。

用“每次事务能耗”做统一度量

把四类瓶颈统一到能耗上，才能做有效取舍。假设某 BLE 温湿度传感器每 5 分钟上报一次，采用 AES-128-GCM 加密 32 字节负载，并每 24 小时做一次 ECDH P-256 密钥协商。可建立如下示例预算（均为合理假设，用于说明方法）：

合计约 20 mJ/天。若电池为 220 mAh、3 V，总能量约 2376 J，理论上可支撑数十年，但实际还要叠加休眠漏电、传感器和 DC-DC 损耗。这个示例说明：通信能耗通常远大于密码计算能耗，因此优化重点往往不是把 AES 再提速 20%，而是减少射频开启次数、缩短连接事件、压缩证书链。

常见瓶颈的定位与处理

• 握手超时或重传：若 ECDH 或 RSA 运算超过协议栈超时窗口，会触发重传，射频时长成倍增加。处理方式是改用更轻的曲线（如 Curve25519 在部分实现上更快）、启用会话复用，或把密钥协商移到设备唤醒后的低占空比窗口。
• RAM 峰值导致任务失败：ECC 或 RSA 运算期间若与协议栈缓冲区叠加，可能触发堆溢出。可在链接脚本中为密码运算预留独立栈区，或改用流式哈希减少中间缓冲。
• Flash 放不下证书链：可只存根证书指纹，用预共享密钥或轻量证书替代完整链；也可把不常用算法编译为可选模块，按需裁剪。
• 能耗异常偏高：先测射频开启时长，再测 CPU 活跃时长。若射频占比高，优先优化通信；若 CPU 占比高，再考虑硬件加速或算法替换。

权衡不是找唯一最优，而是匹配约束

计算、存储、通信与能耗之间没有绝对最优解。安全等级、实时性、电池容量、成本、认证要求共同决定取舍。例如，医疗设备可能更看重确定性和认证合规，愿意用硬件安全模块换取稳定功耗；而一次性标签可能更看重成本，接受较弱的密钥长度和更长的通信窗口。工程上可行的做法是：先明确每次事务的能耗预算和最大时延，再列出候选算法与协议组合，用实测或估算数据逐项打分，最后选择满足安全底线且能耗最低的方案。这样，密码性能优化才不是盲目调参，而是有依据的系统权衡。