Which encryption algorithm should be used in mobile app? TEA

Many app products have a demand for communication encryption, part of the market’s requirements, such as Apple’s mandatory regulations for “ATS”, part of their safety, such as the protection of accounts and passwords. Most of these demands can be upgraded with simple http -> https, and almost no cost (except for plus decryption calculation expenses), such as the Let’s Encrypt free certificate introduced by my previous article.

But there is also a special requirement, HTTPS can’t be solved, that is, the demand for anti-protocol analysis. Many app developers should know that as long as you install a proxy CA certificate in your mobile phone, you can implement intermediary attacks, and grab the apparent content of the HTTPS package through agent software. Although such an attack is difficult to perform on the public network, it is widely used as a debugging means for the APP and the server communication.

What can I do with the agreement? You can guess a certain APP internal logic, you can check the product data. For example: Your app is promoted through a channel, in order to install, register or day live, you often burn a point in the app. When the app starts, some information is sent to the server. If this agreement is cracked, the channel business does not need to be truly promoted, just construct some fake news to send it to your server. You may think that this channel promotion effect is particularly good, in fact, just a scam.

In this case, additional data protection is required for the content of the sensitive protocol. The most common practice is an additional encryption of the contents of the protocol. For performance, a symmetric encryption algorithm is often selected. So, when the problem is coming, Which encryption algorithm should I choose when the mobile app is developed?

About this selection, the domestic Internet circle has a strange situation worth talking about, that is, the TEA algorithm. Because the algorithm has a wide range of applications in Tencent, it is respected by many client developers. Typical recommendations are often: “The TEA encryption algorithm is not only simple, but also has a strong anti-differential analysis ability, and the encryption speed is also faster, and the number of encryption is increased according to the demand.” is this real? Algorithm security can directly see the introduction of the TEA algorithm on Wikipedia, my understanding is not safe enough. But in fact, most users don’t care so much of its safety strength, then? Is the encryption speed really fast?

This is going to see from the perspective of history. As a programmer who has passed the “DES differential password attack” code, it means that the TEA algorithm is sufficiently simple enough. In that age in QQ, TEA has indeed a small advantage in the calculation. But QQ has been 18 years old. The students have changed in China in 18 years, and how much changes have happened in the world!

In 2008, Intel released the X86 AES instruction set extension, and the server CPU in recent years should support, don’t believe you.

GREP AES / PROC / CPUINFO can be seen; 2011 ARM also provides AES and SHA-1 / SHA-256 instructions under ARMV8 architecture. what does that mean? Means that the server and client support AES directly on the hardware, meaning that the original N-compilation instructions only need one AES directive to be completed. In fact, it also means that in most cases, AES should be your first choice.

There is no mouth, we can take a look at the test data, the X86 server CPU test can directly see the Crypto ++ Benchmark. It can be seen that AES / CTR (128-bit Key) and Tea / CTR (128-bit Key) encryption speed ratio is: 4499 mb / s ratio of 72 Mb / s, 62 times! This is the power of hardware implementation.

ARM mobile phone CPU encryption algorithm Benchmark, I didn’t find it. But in order to be more convincing, I realize two test App, an Android version, an iOS version. Write a technical article is not easy, write three evening code before writing blogs, tears! ! ! The code is in https://github.com/solrex/cipher-speed, Android version can scan the code directly in Release.

First, introduce the current flagship CPU, Snapdragon 835 (MSM8998) performance, the test model is Xiaomi 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 can be seen, TEA: AES16: 990, how many times? I am too lazy. Then, 2 years ago, the low-end CPU, Lianfa Helio P10 (MT6755), the test model is charm blue 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 # te: * [TEA] ENC: 6.2 Kb / ms * [TEA] DEC: 8.0 KB / MS then 3 years ago flagship CPU, Apple A8, the test model is iPhone6. Don’t ask me, don’t use this year’s Apple flagship 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 # teaxit ENC: 10.9 Kb / ms * [TEA] Dec: 11.1 kb / ms About Apple A8 Test Many words. I have a lot of gaps from the A8 AES Single Core released from Geekbench, and I don’t know if it is the difference between test methods. But in general, it does not affect the conclusion, that is, TEA and AES gap are huge.

Seeing this, most people have made a choice. Even if you haven’t made a choice of readers, I think you can also consider see if my code has problems. But in the end, I still answer the beginning of the question:

If you use a platform language to achieve symmetrical encryption, it is also using Java on Android, IOS, using OC or SWIFT, AES is not bilateral. This makes it possible to make full use of hardware, security + performance is definitely optimal, don’t think other options.

If you use the Native language to achieve symmetrical encryption, use JNI to call C to compile C compiled in Android, it is difficult to think that native instructions are more difficult to reverse. It may be necessary to make a hierarchy on the ARM architecture. Is it a user who is pleased to pleases the V7, which may affect the selection. But I think AES is still a good option, at least in the server, you will definitely save costs.