聊聊 cipher 加密这事儿,我踩过不少坑,今天就跟大家伙儿唠唠我这段时间的实践体会,说说到底选哪个加密方式才算是最靠谱的。
刚开始搞这个项目的时候,我图省事,直接上手 AES。
AES 确实是应用广,网上资料一大把,找个成熟的库就能开干。我寻思着,这玩意儿加密解密速度快,对称加密,用起来方便,数据量大的时候性能杠杠的。
我先用 AES-CBC 模式跑起来了,密钥管理啥的都简单,直接存在配置文件里,心想先跑起来再说,后续再优化密钥管理。

结果,跑了没多久,安全同事就找上门了。他一句话点醒我:“你这密钥明文放在那儿,跟没加密有啥区别?” 听他一顿分析,我才意识到 AES-CBC 模式下,如果初始向量(IV)不随机,或者密钥管理不当,很容易被攻击,特别是遇到相同明文加密,密文开头都会一样,特征太明显了。
碰壁之后,我赶紧研究了下其他的 AES 模式。切换到 AES-GCM 模式,这个好歹带了认证标签(Authentication Tag),至少保证了数据的完整性。我把 IV 每次都随机生成,然后和密文一起存起来。
这个改动之后,安全性是提高了不少,但随之而来的是操作变复杂了。每次加密,我得生成 IV,算 Tag,然后把 IV、密文、Tag 三部分拼起来传输。接收方也得做逆向操作,验证 Tag,确认没被篡改。这流程走下来,代码量蹭蹭往上涨。
用了一段时间 AES-GCM,数据量上去后,性能瓶颈又不明显了,主要是 I/O 占了大头。可我这应用场景需要的是高频、小数据的加密传输,比如用户的一些敏感操作指令,我希望速度快点,越快越

后面我瞅了瞅现在业界都在推崇的 ChaCha20-Poly1305。这玩意儿据说在移动端和一些资源受限的环境里表现更因为它不需要查表,纯粹的位操作,速度理论上比 AES 快不少。
我决定试着引入 ChaCha20。我这边主要用的是 Go 语言环境,找了第三方库实现了 ChaCha20-Poly1305 的算法。替换掉 AES 的逻辑,我发现代码结构确实简洁了一些,因为它的操作模式天然就包含了认证,不用像 GCM 那样处理 IV、密文、Tag 三块的拼接和分离,它通常把 Nonce(相当于 IV)和密文直接打包,少了好几步操作。
实践下来,ChaCha20 的性能提升确实有点,尤其是在 CPU 不太够的时候,但最让我满意的是它逻辑上的统一性。Poly1305 作为认证算法,流程非常顺畅。
我现在对这些加密方法的选择,总结出这么几条:
说白了,没有绝对“最好”的 cipher,只有“最适合当前场景”的 cipher。我就是这么一步步试错,从 CBC 到 GCM,过渡到 ChaCha20,才算摸索出了适合我们家这个业务场景的加密组合拳。