Android application: DES or RSA?

Question

i created an Android Application that reads data from sensors mounted onto smartphone and sent this data in JSON format to an application server.

I configured server and android app to work over https protocol and to authenticate themselves with a mutual autentication (made up with self-signed certificates).

Now, I was asked to add, in the Android application, the encryption before the client and the server start the authentication process.

In this regard, I want to understand what is the best algorithm between DES and AES from resource consumption point of view.

I don't find anything on web. Can you redirect me to some resource where i can understand more about this argument?

Answer 1

DES is deprecated in almost all legitimate uses of symmetric encryption (it is obsolete and easily brute-forceable). AES (Rijndael with block size of 128 bits) is the standard symmetric encryption solution, while Blowfish, Twofish, RC4 (also not suggested), and 3DES/TDES are other options. AES is universally supported and will be your best solution in this case. Android has support for AES encryption through native Java JCA (formerly JCE) libraries as well as SpongyCastle -- a modified version of BouncyCastle designed for Android).

If you need something more substantial to back this up, there are plenty of resources:

• Thomas Pornin discusses the differences between DES and AES
• Thomas Pornin again
• Christian Dobre
• Thomas Pornin on speed differences between AES and 3DES
• Summary (and additional links) of AES performance

You should use a strong (128 or 256 bit) key generated from a CSPRNG (or securely derived from a strong passphrase via PBKDF2, bcrypt, or scrypt with high work factor/iterations), a unique and non-predictable IV for each encryption operation, and (preferably) an authenticated encryption with associated data (AEAD) cipher block mode of operation like GCM or EAX, or failing that, a HMAC-based message authentication code (MAC) over the cipher text and verify it with a constant-time equality check before performing any decryption.

Answer 2

Don't ever use DES. It's positively antique (over 40 years old) and the short key length (56 bits) means it can nowadays be cracked quite quickly with modest hardware.

Its weakness was recognized some time ago, which is why Triple DES (3DES) was introduced to offer better security (increasing the key length to 112 bits). However, this came at the expense of increased computation times, since the algorithm has to do considerably more work to encrypt each block of data.

AES beats 3DES in every respect. By design, it is able to operate at high speed with low memory requirements. Furthermore, the latest processors (including Intel x86 and ARM architectures) have built-in AES instructions that allow encryption and decryption to be performed in hardware, resulting in speeds that are orders of magnitude higher than would be possible with 3DES.

Answer 3

I have to agree with the other answers as regards DES - it provides little defense against a motivated attacker.

In terms of RSA (the other algorithm you mention in your title), public-key encryption algorithms are generally considerably slower (by a magnitude of about 1000 based on what I've read, although I've never personally timed it).

It's also arguably less secure to use public-key cryptography for exchanging long messages.

As some background, public-key cryptography generally depends on some kind of a trap-door function (i.e. a function that is relatively easy to compute but is difficult to find the inverse for). It turns out that those functions are remarkably difficult to find; one of the most common ones now (which is what RSA is based on) is integer factorization, which is NP-Intermediate on "standard" computers (but is broken for quantum computers).

First, the fact that integer factorization is NP-intermediate is at least a theoretical weakness in RSA - technically, no one's actually proven that NP-intermediate problems are intrinsically more "difficult" than polynomial-time algorithms (although it's widely believed that they are) because that would entail solving the P vs. NP problem, which is one of the major outstanding questions in computer science.

It turns out that many of the trap-door functions aren't quite as difficult to find inverses for as it is to break a good symmetric-key algorithm like AES or Twofish - i.e. the best public cryptanalysis for public-key encryption algorithms tend to be at least somewhat more feasible than the ones for symmetric-key algorithms. (There's a good article here on why it's completely infeasible to "break" AES with brute force, and the known attacks against it aren't even close to feasible either).

For this reason, public-key cryptography's often used for things like key exchange, at which point both parties switch to symmetric-key cryptography.

All that to say that the other people are right - use AES :).