共计 1263 个字符，预计需要花费 4 分钟才能阅读完成。
我在 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 上的定位基本就清楚了。它是能用的，而且成本也不算离谱，但前提是你得把它放在对的位置上。用来做低频、关键的安全校验，它是很合适的；但如果指望它去承担高频或者大数据量的任务，那基本就是用错地方了。
说到底，这东西不是用来让系统看起来“更高级”的，而是在关键时候，能让你心里更有底。
