很多 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 依然是一个好的选项，起码在服务器端，你肯定会节省成本。

建议继续学习：

1. 网址加密(URL加密)（RC4、PHP、密钥长度可变）    (阅读：6924)
2. 在浏览器中加密Cookie    (阅读：4567)
3. 代理的加密部分    (阅读：4516)
4. 使用bcompiler对PHP文件进行加密    (阅读：4342)
5. 使用系统命令实现文件的压缩与加密    (阅读：4027)
6. 公钥私钥加密解密数字证书数字签名详解    (阅读：4013)
7. 可逆的加密方法(Mcrypt Encryption Functions)    (阅读：3702)
8. 加密你的shell    (阅读：3611)
9. 如何“加密”你的email地址    (阅读：3149)
10. 具有时效性的PHP字符串加密解密函数    (阅读：3110)