tea在c++单片机环境完全可行，但须手写裸函数、禁用stl与动态内存、严格8字节对齐，否则栈溢出或解密错乱；必须用uint32_t*原生指针操作、pkcs#7填充、16/32轮按需选择、密钥显式拆为uint32_t[4]。
直接上结论：TEA 在 C++ 单片机环境里完全可行，但必须手写裸函数、禁用 STL 和动态内存、严格对齐 8 字节块，否则会炸栈或解密错乱。
单片机资源紧、无 OS、无标准库，照搬 PC 端 C++ 实现必然失败。下面说清楚怎么做、为什么、以及最容易翻车的几个点。
tea_encrypt/tea_decrypt 函数必须用 uint32_t * 原生指针操作
单片机没有 std::vector 或 std::string，所有数据都得是静态数组 + 指针传参。函数签名只能是：
void tea_encrypt(uint32_t *v, const uint32_t *k); void tea_decrypt(uint32_t *v, const uint32_t *k);
其中 v 是长度为 2 的 uint32_t 数组（即 8 字节），k 是长度为 4 的 uint32_t 数组（即 16 字节密钥）。不能传 std::array，不能传引用，不能用模板封装——编译器可能内联失败或生成冗余代码。
- 务必确保
v地址 4 字节对齐（多数 Cortex-M 默认满足，但若从字节数组强转需检查） -
k建议定义为static const uint32_t key[4] = {0x12345678, ...}，避免从 Flash 读取慢 - 别用
long——在 MSP430 上是 16 位，在 STM32 上是 32 位，必须显式用uint32_t
数据分块加密前必须做 PKCS#7 填充
TEA 只处理 8 字节块，而实际通信包长往往不是 8 的倍数（比如 13 字节指令）。不填充就直接切块加密，最后 5 字节会被截断或越界读写。
正确做法是手动实现 PKCS#7：
- 计算需填充字节数：
pad_len = 8 - (len % 8)；若len % 8 == 0，仍要填 8 字节（即全填0x08） - 在原始数据末尾追加
pad_len个值为pad_len的字节 - 加密后总长变为
len + pad_len，解密后按最后一个字节值截掉尾部
示例：明文 "HELLO"（5 字节）→ 填 3 字节 → "HELLO\x03\x03\x03"；解密后读 buf[len-1] 得到 3，再 len -= 3 即可还原。
迭代轮数选 16 还是 32？取决于你的威胁模型和时钟预算
QQ 用 16 轮，嵌入式常见也用 16 轮 —— 不是因为“够用”，而是因为：
- 在 6 MHz MSP430 上，16 轮比 32 轮快一倍（实测：~120μs vs ~240μs/8 字节）
- 差分攻击对 16 轮 TEA 已有理论突破，但要求大量已知明文对；单片机点对点短消息场景下，攻击面极窄
- 若用 32 轮，
sum初始值必须是0xC6EF3720（即delta * 32），而 16 轮对应的是0xE3779B90；混用会导致解密失败
所以：资源紧张或实时性敏感 → 用 16 轮；协议要求高安全（如固件升级包）→ 改 32 轮，并同步更新解密端 sum 初始值。
密钥硬编码在 Flash 里，但千万别用字符串字面量直接赋值
错误写法：const char key_str[] = "my_secret_128bit"; → 这是 16 字节 ASCII，不是 4 个 uint32_t，直接传给 tea_encrypt 会把字符当小端整数解析，结果全错。
正确做法是显式拆成 32 位字：
static const uint32_t tea_key[4] = {
0x01020304, // 对应字节数组 [0x01,0x02,0x03,0x04]
0x05060708,
0x090A0B0C,
0x0D0E0F10
};
如果密钥来自配置区（如 EEPROM），读出来后必须按小端顺序组装成 uint32_t[4]，不能 memcpy 原样塞进去。
最常被忽略的一点：TEA 没有 IV，也没有模式切换概念，它就是纯 ECB —— 同一明文块永远加密成同一密文块。如果你反复发送相同指令（如“开灯”），网络嗅探者能靠密文重复性识别行为。真要防这个，得自己加随机 nonce 前缀再哈希裁剪，或者换 XTEA（支持轮密钥扰动）。但那就不是“轻量级”了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
