手机 APP 应该选用哪个加密算法 - 兼吐槽 TEA

标签： 安全 | 发表时间：2019-03-27 21:16 | 作者：Solrex
出处：http://www.blogread.cn/it/

标签：   TEA   加密

   很多 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. Burpsuite插件开发之RSA加解密 [2016-02-11 22:37:04]
  2. 文档安全加密系统的实现方式 [2016-02-06 11:19:22]
  3. 公钥私钥加密解密数字证书数字签名详解 [2014-04-21 12:44:29]
  4. Perl 程序源码怎么加密 [2013-05-28 22:20:58]
  5. 网址加密(URL加密)（RC4、PHP、密钥长度可变） [2012-12-21 13:38:39]
  6. 跨越千年的RSA算法 [2012-12-16 23:46:00]
  7. 加密服务学习笔记 [2012-05-08 00:07:39]
  8. Oracle Transparent Data Encryption - 透明数据加密 [2011-09-14 13:58:49]
  9. 在浏览器中加密Cookie [2011-06-02 23:44:09]
  10. 如何“加密”你的email地址 [2011-02-13 22:51:37]
  11. Padding Oracle Attack实例分析 [2011-02-10 22:33:42]
  12. 加密你的shell [2010-11-14 21:05:30]
  13. 具有时效性的PHP字符串加密解密函数 [2010-05-22 13:04:30]
  14. 代理的加密部分 [2010-04-01 08:51:34]
  15. 使用bcompiler对PHP文件进行加密 [2010-03-26 14:21:55]
  16. 使用系统命令实现文件的压缩与加密 [2009-11-19 22:41:24]
  17. 可逆的加密方法(Mcrypt Encryption Functions) [2009-10-16 12:06:43]

相关 [手机 app 加密算法] 推荐：

手机 APP 应该选用哪个加密算法 - 兼吐槽 TEA

- - IT技术博客大学习
标签：   TEA   加密.    很多 APP 产品都有通信加密的需求，一部分出于市场的要求，比如苹果对于“ATS”的强制性规定，一部分出于自身安全的考虑，比如对账号和密码的保护. 这些需求大部分都可以用简单的 HTTP -> HTTPS 升级来搞定，而且几乎不用付出什么成本（除加解密的计算开支外），例如使用我之前文章介绍到的 Let's Encrypt 免费证书.

创意手机APP汇总

- ArBing - 月光博客
　　在知乎上有人讨论“如果由你来创意一个手机app，它是什么样的”，网友有很多有意思的想法，因为对移动互联网这一块很感兴趣，所以把网友们的想法汇总一下，一来通过整理的过程想想app实现的可能性和实现后的潜力，二来抛砖引玉，希望能引发网友更多的思考. 分析提取照片中人物的衣着，列出每项价格及其相关服装对比，支持在线购买.

银联加密算法

- - CSDN博客推荐文章
很多人对银联卡的加密算法感兴趣，毕竟分分钟涉及的都是你的钱的安全，但网上很少人却讲银联标准加密算法. 遂写一遍当做是自己的学习笔记，偶尔忘了可以翻翻，同时希望能够帮助到其他人. 首先要认识一下cbc算法和ecb算法. cbc算法是链式的，慢，不可并行处理，但更安全，因为每一次加密都是依赖于上一次的结果，同时这也会导致一次错将导致后面的全部错误.

关于手机App的Https抓包

- - 火丁笔记
我喜欢用 Mitmproxy 来处理手机 App 抓包之类的工作，本来用它来抓 Https 包是很容易的一件事，只要设置好代理，浏览 mitm.it 按提示安装证书即可，可是当 Android 版本升级到 7 以后，此方法就失效了，为什么呢. 因为新版 Android 缺省情况下只信任系统级证书，而不再信任用户级证书，问题详细描述可以参考： 听说安卓微信 7.0 不能抓 https?.

AES加密算法动画演示

- Charles - 酷壳 - CoolShell.cn
波士顿大学的Howard Straubing做了这么一个动画来展示AES加密算法的演示，挺不错的. 2009年08月10日 -- 几个有趣的漫画. 2010年04月23日 -- McAfee误杀svchost.exe. 2010年05月23日 -- （麻省理工免费课程）C语言内存管理和C++面向对象编程.

AES加密算法强度被削弱

- sec314 - cnBeta.COM
密码学研究者在AES加密算法中发现一处弱点，这使得破解密钥的速度比以前更快了. 发现这个弱点的是三个大学中的研究人员以及微软公司，他们进行了大量的密码学分析，但这个研究结果仍然不能形成什么实际的安全威胁――这反而让人更加放心了.

RC4加密算法的JS实现

- - 博客园_首页
RC4是一种简单的对称加密算法，在文本加密，通信加密等场景应用非常广泛. 在Web中可以用来对本地存储数据进行加密，比如存储cookie中的用户名和密码，敏感信息等. 以下是本人根据其思想基于JS实现的算法. //var  ctext = rc4("我是明文","我是密码");. //var text = rc4(ctext, "我是密码");.

Javascript常见加密算法库

- - 脚本爱好者
CryptoJS (crypto.js) 为 JavaScript 提供了各种各样的加密算法. CryptoJS在Google Code上的主页是： http://code.google.com/p/crypto-js/.

简单、高效加密算法TEA

- - 互联网 - ITeye博客
TEA（Tiny Encryption Algorithm）是一种分组加密算法，它的实现非常简单，通常只需要很精短的几行代码. （1）客户端桌面程序或手机程序与服务端接口交互，可以使用TEA来进行加密，保证传输信息的私密性. 如：OICQ的数据安全采用了TEA算法，QQ通讯也大量使用了TEA算法. （2）存储在本地的用户私密信息，可以采用TEA加密算法.

HTTPS背后的加密算法

- - 博客园_知识库
　　当你在浏览器的地址栏上输入https开头的网址后，浏览器和服务器之间会在接下来的几百毫秒内进行大量的通信. InfoQ的这篇 文章对此有非常详细的描述. 这些复杂的步骤的第一步，就是浏览器与服务器之间协商一个在后续通信中使用的密钥算法. 浏览器把自身支持的一系列Cipher Suite（密钥算法套件，后文简称Cipher）[C1,C2,C3, …]发给服务器；.