密码库基础：主流密码库对比
做嵌入式安全这些年，我接触过的密码库少说也有七八个。每个库都有自己的脾气，选对了事半功倍，选错了……嗯，我在一个IoT项目上就吃过亏，后面会细说。
今天咱们把四个主流密码库——OpenSSL、Mbed TLS、WolfSSL、LibTomCrypt——掰开揉碎聊一遍。不光是罗列特性，我会把实际项目中踩过的坑、哪些场景该用哪个库，一并交代清楚。
四库全景：一张图看懂
先放一张我手绘的结构对比图，帮你快速建立全局认知：
逐个拆解：每个库的脾气秉性
OpenSSL：瑞士军刀，但有点沉
OpenSSL 是密码库界的「老大哥」。功能最全，支持最广，社区最活跃。你想想看，从 HTTPS 到 SSH，从证书管理到各种密码算法，它几乎包圆了。
优点：
- 算法最全：对称、非对称、哈希、HMAC、KDF……你能想到的它都有
- 协议支持完整：TLS 1.3、DTLS 1.2、QUIC（实验性）
- 硬件加速好：AES-NI、ARM CE、PCLMULQDQ 都支持
- 社区庞大：遇到问题 Stack Overflow 一搜就有答案
缺点：
- 体积大：静态链接轻松 2MB+，裁剪后也要 500KB 左右
- API 复杂：我记得刚接触时看
SSL_CTX_new的文档，参数列表能翻三屏 - 内存占用高：一个 SSL 连接轻松吃掉几十 KB 堆内存
适用场景：服务器端、桌面应用、网关设备（内存 > 1MB 且 Flash > 4MB）。
我在一个智能网关项目里用过 OpenSSL，当时觉得「反正 Flash 有 8MB，随便用」。结果产品经理要求加 OTA 升级功能，Flash 不够了……最后被迫切到 Mbed TLS。
Mbed TLS：ARM 的亲儿子，嵌入式首选
Mbed TLS 最初叫 PolarSSL，被 ARM 收购后改名。它的设计哲学就是「为嵌入式而生」。代码结构清晰，模块化做得特别好。
优点：
- 模块化裁剪：你可以只编译需要的算法，比如只要 AES-CBC-128 和 SHA-256，其他全砍掉
- 内存占用低：一个 TLS 连接大约 8-12 KB 堆内存
- ARM 生态好：对 Cortex-M 系列有专门优化，支持 TrustZone
- 文档质量高：每个 API 都有详细说明和示例
缺点：
- 性能一般：纯软件实现，没有 OpenSSL 那种汇编级优化
- 协议支持略慢：TLS 1.3 支持比 WolfSSL 晚了大半年
- 许可证变更历史：早期是 GPL，后来改 Apache 2.0，老项目要注意
我的经验：如果你用 STM32、NXP 这类 ARM MCU，Mbed TLS 是首选。我做过一个 STM32F4 的项目，Flash 512KB、RAM 128KB，用 Mbed TLS 裁剪后只占 80KB Flash，跑 TLS 1.2 完全没问题。
WolfSSL：轻量级冠军，FIPS 认证加持
WolfSSL（以前叫 CyaSSL）是专门为「资源极度受限」场景设计的。它的口号是「20KB 就能跑 TLS」。我一开始不信，直到亲手试了……
优点：
- 体积极小：最小配置下 20-30KB Flash 就能跑 TLS 客户端
- FIPS 140-2/3 认证：有官方认证版本，适合政府、金融项目
- 兼容性好：提供 OpenSSL 兼容 API，迁移成本低
- 支持多平台：RTOS、Linux、Windows、甚至裸机都能跑
缺点：
- 社区相对小：遇到冷门问题可能搜不到答案
- 商用许可证贵：GPLv2 版本免费，商用版要花钱
- 部分算法实现较新：比如 Kyber（后量子密码）支持还在完善中
避坑指南：我曾经在一个电池供电的传感器节点上用了 WolfSSL，Flash 只有 128KB。裁剪后 TLS 客户端只占 35KB，RAM 峰值 6KB。但要注意——WolfSSL 的默认配置会开启很多调试日志，发布前一定要关掉，否则 Flash 会多出 10KB+。
LibTomCrypt：纯算法库，不搞协议
LibTomCrypt 跟上面三个不一样。它只提供密码算法实现，没有 TLS/DTLS 协议栈。说白了，它是一盒「乐高积木」，你自己搭房子。
优点：
- 代码极简：每个算法一个文件，没有复杂的依赖
- Public Domain 许可证：随便用，没有任何法律风险
- 教学价值高：代码可读性好，适合学习算法原理
- 跨平台：纯 C 语言，任何平台都能编译
缺点：
- 没有协议栈：需要自己实现 TLS 或自定义安全协议
- 性能一般：没有汇编优化，大文件加解密较慢
- 缺少高级功能：没有证书管理、OCSP、CRL 等
适用场景：自定义协议、算法教学、资源极度受限且不需要 TLS 的场景。
我在一个 LoRa 传感器项目里用过 LibTomCrypt。因为 LoRa 带宽极低（几百 bps），跑 TLS 握手都不够。我直接用 LibTomCrypt 的 AES-CCM 做数据加密，配合自定义的轻量握手协议，效果很好。
许可证合规性：别踩法律红线
这一点我特别想强调。很多工程师只关注技术指标，忽略了许可证问题。我在一个商业项目里就差点因为 OpenSSL 的许可证问题被法务找上门。
| 密码库 | 许可证 | 商业使用注意事项 |
|---|---|---|
| OpenSSL | Apache 2.0 | 宽松，保留版权声明即可。注意 OpenSSL 早期是双许可证（OpenSSL License + SSLeay License），老版本有广告条款。 |
| Mbed TLS | Apache 2.0 | 宽松，ARM 官方推荐。注意 2.x 版本之前是 GPLv2，升级时检查一下。 |
| WolfSSL | GPLv2 / 商用 | GPLv2 版本要求衍生作品也开源。闭源商业产品需要购买商用许可证。 |
| LibTomCrypt | Public Domain | 最宽松，没有任何限制。可以随意修改、分发、商用。 |
重要提醒：许可证问题不是「先用了再说」。我见过一个创业公司，产品都量产了，法务发现 WolfSSL 的 GPL 许可证跟他们的闭源策略冲突。最后要么花几万美金买商用许可，要么换库重写通信协议——哪个都不好受。
如何选择？我的决策框架
说了这么多，到底怎么选？我一般按这个思路来：
- 先看资源限制：Flash < 200KB 或 RAM < 32KB？直接看 WolfSSL 或 LibTomCrypt。
- 需要 TLS 吗？需要 → 从 OpenSSL/Mbed TLS/WolfSSL 里选。不需要 → LibTomCrypt 可能更合适。
- 有合规要求吗？FIPS 认证 → WolfSSL。其他合规 → 检查许可证是否匹配。
- 团队熟悉度：如果团队都用过 OpenSSL，别为了省 100KB Flash 强行换库——开发成本可能更高。
- 长期维护：选社区活跃、更新频繁的库。OpenSSL 和 Mbed TLS 在这方面最稳。
我的建议：如果拿不准，先用 Mbed TLS 做原型。它模块化好，裁剪方便，许可证也宽松。原型跑通了，再根据实际资源占用决定要不要换更轻量的 WolfSSL。