我在 M4 单片机上跑了一下非对称加密的 ED25519 验签，结论挺真实的

我在 M4 单片机上跑了一下非对称加密的 ED25519 验签，结论挺真实的

最近在国民技术的一颗 M4 上，把 ED25519 的验签流程完整跑了一遍。其实一开始也没抱太大期望，这类非对称算法大家都知道安全性高，但放到 MCU 上，很多时候就是“理论可以，工程不行”。所以我干脆自己跑一轮，看看到底是个什么水平。

测试方式很简单，我没有在 MCU 上做签名，只做验签。上位机用 Python 生成公钥、私钥和签名，然后把 message、signature、公钥传到单片机里去验证。消息我就用了一个最简单的字符串 “i am alive”，目的也很明确，就是把变量压到最低，只看算法本身的性能和资源占用。

跑出来的结果还挺稳定，一秒大概能做 15 次验签，基本就是 60 多毫秒一次。这个数据出来之后，其实心里就有数了，这东西在 MCU 上不是不能用，但绝对不是拿来随便调的函数，它是一个有明显算力成本的操作。你要是想在通信里每条消息都验签，那基本就是自己给系统找麻烦；但如果只是开机校验一次，或者 OTA 的时候验一次，那这个性能是完全够用的。

不过，还要考虑单片机的 Flash 够不够用。

资源这块我也看了一下，原始工程代码大概 7KB，在 O3 优化下把验签加进去之后，整个程序变成了 16KB 多一点，相当于增加了 10KB。这个量级说大不大，说小也不小，如果是那种 Flash 本来就很紧的项目，这一步是需要认真评估的。好在 RAM 占用很低，大概也就一百字节左右，这一点倒是挺友好，不会对系统运行造成什么压力。

做完这轮测试之后，其实有一个很明确的感受，就是很多人对这类算法的定位是有偏差的。ED25519 这种东西，本质上是用来做签名和验签的，是解决“这东西是不是我发的，有没有被改过”的问题，而不是拿来加密大数据的。你看现在这个性能，一秒 15 次，其实已经把它的使用边界画得很清楚了，它就不适合出现在高频路径里。

所以在工程上，我更倾向于把它当成一个“兜底”的安全机制来用。真正跑数据的部分，还是应该交给 AES 这种对称算法去做，效率高、成本低；ED25519 只在关键节点用一下，比如建立信任、校验固件，这样既把安全性补上了，也不会把系统拖慢。

这次我也刻意只在 MCU 上做验签，没有做签名，这其实也是一个比较标准的用法。私钥这种东西没必要也不应该放在设备侧，一旦进了设备，就总有被拿走的风险。再加上签名本身比验签更耗资源，让 MCU 去做这件事意义也不大。所以更合理的分工就是，上位机或者云端负责签名，设备只保留公钥做验证。

结合设备的 OTA 系统，这套东西其实是可以直接用起来的。升级包在生成的时候做一次签名，设备在写入之前做一次验签，通过了再刷，不通过就直接丢掉，这一步能挡掉很多乱七八糟的风险。

这一轮跑下来，对 ED25519 在 MCU 上的定位基本就清楚了。它是能用的，而且成本也不算离谱，但前提是你得把它放在对的位置上。用来做低频、关键的安全校验，它是很合适的；但如果指望它去承担高频或者大数据量的任务，那基本就是用错地方了。

说到底，这东西不是用来让系统看起来“更高级”的，而是在关键时候，能让你心里更有底。