很多 APP 产品都有通信加密的需求，一部分出于市场的要求，比如苹果对于“ATS”的强制性规定，一部分出于自身安全的考虑，比如对账号和密码的保护。这些需求大部分都可以用简单的 HTTP -> HTTPS 升级来搞定，而且几乎不用付出什么成本（除加解密的计算开支外），例如使用我之前文章介绍到的 Let's Encrypt 免费证书。
但还有一类特殊的需求，HTTPS 解决不了，也就是防协议分析的需求。很多 APP 开发者应该知道，只要在手机里安装一个代理 CA 证书，就可以实现中间人攻击，通过代理软件抓到 HTTPS 包的明文内容。虽然这样的攻击很难在公开网络上进行，但对自己的手机进行抓包分析，作为 APP 和服务端通信的调试手段是被广泛使用的。
协议分析能做什么呢？可以猜想到一定的 APP 内部逻辑，可以对产品数据进行作弊攻击。举个例子：你的 APP 通过某个渠道进行推广，为了统计渠道安装、注册或者日活，你往往会在 APP 中埋一个点，当 APP 启动时，发送一些信息到服务器。如果这个协议被破解了，渠道商根本不需要真正进行推广，只需要构造一些假消息发送到你的服务器就行了。仅看数据你可能会以为这个渠道推广效果特别好，其实只是骗局而已。
这类情况下，就要求对敏感协议内容进行额外的数据保护。最常用的做法，就是对协议内容进行一次额外的加密，为了性能，往往选用对称加密算法。那么问题来了，手机 APP 开发时，应该选用哪个加密算法？
关于这个选型，国内互联网圈有个怪现状值得谈一下，那就是 TEA 算法。因为该算法在腾讯有着广泛的应用，因而被很多客户端开发人员推崇。典型推荐理由往往是：“TEA加密算法不但比较简单，而且有很强的抗差分分析能力，加密速度也比较快，还可以根据需求设置加密轮数来增加加密强度”。这是真的吗？算法安全性可以直接看维基百科上 TEA 算法的介绍，我的理解是不够安全。但其实大部分用户也不那么地在乎它的安全强度，那么性能呢？加密速度真的很快吗？
这就要从历史的角度去看了。作为曾经手撸过 “DES 差分密码攻击” 代码的程序员，表示 TEA 算法的确足够简单。在 QQ 诞生的那个年代，TEA 在计算上的确有着不小的优势。但 QQ 已经 18 岁了啊同学们，18 年来中国发生了多大的变化，世界发生了多大的变化啊！
2008 年，Intel 就发布了 x86 的 AES 指令集扩展，近几年的服务器 CPU 应该都支持，不相信你
grep aes /proc/cpuinfo 就能看到 ；2011 年 ARM 也在 ARMv8 架构下直接提供了 AES 和 SHA-1/SHA-256 指令 。这意味着什么？意味着服务端和客户端在硬件上直接支持 AES，意味着原来 N 条汇编指令只需要一条 AES 指令就完成了。其实也意味着，在绝大多数情况下 AES 才应该是你的首选。
口说无凭，咱们可以看一下测试数据，x86 服务器 CPU 测试可以直接看 Crypto++ 的 benchmark 。可以看到 AES/CTR (128-bit key) 与 TEA/CTR (128-bit key) 的加密速度比是：4499 MB/s 比 72 MB/s，62 倍的差异！这就是硬件实现的威力。
ARM 手机 CPU 加密算法的 Benchmark，我没有找到。但为了更有说服力，我自己实现了两个测试 APP，一个 Android 版，一个 iOS 版。写技术文章多不容易啊，写博客之前先写三个晚上代码，泪目！！！代码在 https://github.com/solrex/cipher-speed ，Android 版可以直接在 Release 里扫码安装。
首先介绍一下目前的旗舰 CPU，骁龙 835 (MSM8998) 的表现，测试机型是小米 6：
# Speed Test of 10MB Data Enc/Decryption #
# AES:
* [AES/CBC/PKCS5Padding] ENC: 1146.9 KB/ms
* [AES/CBC/PKCS5Padding] DEC: 692.4 KB/ms
* [AES/CBC/NoPadding] ENC: 1118.8 KB/ms
* [AES/CBC/NoPadding] DEC: 1343.5 KB/ms
* [AES/ECB/PKCS5Padding] ENC: 990.4 KB/ms
* [AES/ECB/PKCS5Padding] DEC: 703.2 KB/ms
* [AES/ECB/NoPadding] ENC: 973.4 KB/ms
* [AES/ECB/NoPadding] DEC: 988.9 KB/ms
* [AES/GCM/NOPADDING] ENC: 13.9 KB/ms
* [AES/GCM/NOPADDING] DEC: 14.7 KB/ms
# DES:
* [DES/CBC/PKCS5Padding] ENC: 20.1 KB/ms
* [DES/CBC/PKCS5Padding] DEC: 20.7 KB/ms
* [DES/CBC/NoPadding] ENC: 21.3 KB/ms
* [DES/CBC/NoPadding] DEC: 21.6 KB/ms
* [DES/ECB/PKCS5Padding] ENC: 26.3 KB/ms
* [DES/ECB/PKCS5Padding] DEC: 26.2 KB/ms
* [DES/ECB/NoPadding] ENC: 25.9 KB/ms
* [DES/ECB/NoPadding] DEC: 26.8 KB/ms
# 3DES:
* [DESede/CBC/PKCS5Padding] ENC: 23.6 KB/ms
* [DESede/CBC/PKCS5Padding] DEC: 23.2 KB/ms
* [DESede/CBC/NoPadding] ENC: 23.6 KB/ms
* [DESede/CBC/NoPadding] DEC: 23.5 KB/ms
* [DESede/ECB/PKCS5Padding] ENC: 8.5 KB/ms
* [DESede/ECB/PKCS5Padding] DEC: 8.5 KB/ms
* [DESede/ECB/NoPadding] ENC: 8.5 KB/ms
* [DESede/ECB/NoPadding] DEC: 8.6 KB/ms
# TEA:
* [TEA] ENC: 16.0 KB/ms
* [TEA] DEC: 18.1 KB/ms可以看到，TEA:AES=16:990，这是多少倍？我都懒得算了。然后是 2 年前的中低端 CPU，联发科 Helio P10 (MT6755)，测试机型是魅蓝 Note 3：
# Speed Test of 10MB Data Enc/Decryption #
# AES:
* [AES/CBC/PKCS5Padding] ENC: 358.8 KB/ms
* [AES/CBC/PKCS5Padding] DEC: 267.9 KB/ms
* [AES/CBC/NoPadding] ENC: 438.8 KB/ms
* [AES/CBC/NoPadding] DEC: 515.0 KB/ms
* [AES/ECB/PKCS5Padding] ENC: 310.6 KB/ms
* [AES/ECB/PKCS5Padding] DEC: 222.1 KB/ms
* [AES/ECB/NoPadding] ENC: 312.4 KB/ms
* [AES/ECB/NoPadding] DEC: 319.5 KB/ms
* [AES/GCM/NOPADDING] ENC: 5.1 KB/ms
* [AES/GCM/NOPADDING] DEC: 5.7 KB/ms
# DES:
* [DES/CBC/PKCS5Padding] ENC: 7.5 KB/ms
* [DES/CBC/PKCS5Padding] DEC: 7.7 KB/ms
* [DES/CBC/NoPadding] ENC: 7.7 KB/ms
* [DES/CBC/NoPadding] DEC: 7.8 KB/ms
* [DES/ECB/PKCS5Padding] ENC: 9.3 KB/ms
* [DES/ECB/PKCS5Padding] DEC: 9.2 KB/ms
* [DES/ECB/NoPadding] ENC: 9.3 KB/ms
* [DES/ECB/NoPadding] DEC: 9.5 KB/ms
# 3DES:
* [DESede/CBC/PKCS5Padding] ENC: 12.5 KB/ms
* [DESede/CBC/PKCS5Padding] DEC: 12.3 KB/ms
* [DESede/CBC/NoPadding] ENC: 12.3 KB/ms
* [DESede/CBC/NoPadding] DEC: 12.5 KB/ms
* [DESede/ECB/PKCS5Padding] ENC: 3.1 KB/ms
* [DESede/ECB/PKCS5Padding] DEC: 3.1 KB/ms
* [DESede/ECB/NoPadding] ENC: 3.1 KB/ms
* [DESede/ECB/NoPadding] DEC: 3.1 KB/ms
# TEA:
* [TEA] ENC: 6.2 KB/ms
* [TEA] DEC: 8.0 KB/ms然后是 3 年前的旗舰 CPU，Apple A8，测试机型是 iPhone6。别问我为啥不用今年的苹果旗舰 CPU...
# Speed Test of 10MB Data Enc/Decryption #
# AES
* [AES/CBC/PKC7Padding] ENC: 76.0 KB/ms
* [AES/CBC/PKC7Padding] DEC: 111.3 KB/ms
* [AES/CBC/NoPadding] ENC: 138.2 KB/ms
* [AES/CBC/NoPadding] DEC: 450.7 KB/ms
* [AES/ECB/PKC7Padding] ENC: 305.6 KB/ms
* [AES/ECB/PKC7Padding] DEC: 735.9 KB/ms
* [AES/ECB/NoPadding] ENC: 330.0 KB/ms
* [AES/ECB/NoPadding] DEC: 673.6 KB/ms
# DES
* [DES/CBC/PKC7Padding] ENC: 23.1 KB/ms
* [DES/CBC/PKC7Padding] DEC: 24.5 KB/ms
* [DES/CBCPadding] ENC: 23.1 KB/ms
* [DES/CBCPadding] DEC: 22.8 KB/ms
* [DES/ECB/PKC7Padding] ENC: 19.4 KB/ms
* [DES/ECB/PKC7Padding] DEC: 20.8 KB/ms
* [DES/ECBPadding] ENC: 22.2 KB/ms
* [DES/ECBPadding] DEC: 22.2 KB/ms
# 3DES
* [3DES/CBC/PKC7Padding] ENC: 9.7 KB/ms
* [3DES/CBC/PKC7Padding] DEC: 9.8 KB/ms
* [3DES/CBC/NoPadding] ENC: 9.8 KB/ms
* [3DES/CBC/NoPadding] DEC: 9.8 KB/ms
* [3DES/ECB/PKC7Padding] ENC: 9.4 KB/ms
* [3DES/ECB/PKC7Padding] DEC: 9.1 KB/ms
* [3DES/ECB/NoPadding] ENC: 9.2 KB/ms
* [3DES/ECB/NoPadding] DEC: 9.4 KB/ms
# TEA
* [TEA] ENC: 10.9 KB/ms
* [TEA] DEC: 11.1 KB/ms关于 Apple A8 的测试多说两句。我上面的 AES 性能，离 GeekBench 发布的 A8 AES Single Core 还有不少差距，不知道是不是测试方法差异导致。但总的来说，不影响结论，那就是 TEA 跟 AES 差距巨大。
看到这里，可能大部分人心里已经做出选择了。即使还没做出选择的读者，我想你也可以考虑看看我的代码实现是否存在问题。不过最后还是回答一下开头提出的问题吧：
如果你使用平台语言来实现对称加密，也就是 Android 上用 Java，iOS 上用 OC 或者 Swift，AES 是不二选择。这样能充分利用硬件提供的能力，安全性+性能肯定是最优，不要再想其他选项了。
如果你使用 Native 语言来实现对称加密，在 Android 上使用 JNI 调用 C 编译的代码，的确不少人认为原生指令更难逆向。可能要在 ARM 架构上做个取舍，是取悦 v8 用户，还是取悦 v7 以下的用户，这可能影响到选型。不过我认为 AES 依然是一个好的选项，起码在服务器端，你肯定会节省成本。