Encryption in Mobile Apps — Fundamentals, Algorithms, and How It Works

What Is Encryption in Mobile Applications?

Encryption in the context of mobile applications is the application of cryptographic algorithms to protect data stored on the device (data at rest) and transmitted over the network (data in transit). At the device level, local storage is encrypted: files, databases, SharedPreferences, and cache. At the network level, traffic between the app and the server is encrypted via TLS/HTTPS protocols. The ultimate goal is to ensure that even with physical access to the device or traffic interception, an attacker cannot read the protected data without the cryptographic key.

Why Encryption Is Needed in Mobile Applications

Mobile devices are particularly vulnerable to data loss: a phone can easily be lost, stolen, or infected with malware. According to the Ponemon Institute (2023), 42% of companies affected by data breaches attribute incidents to mobile devices. Without encryption, an attacker can connect to the device via USB, extract the SQLite database, and read all stored data. Encryption solves this problem: even if the database is extracted, its contents remain encrypted. Additionally, the US and EU have laws (GDPR, CCPA) requiring encryption of personal data and imposing fines of up to 4% of annual turnover for violations. Using encryption is not only a technical but also a legal necessity for any mobile application that handles user data.

Symmetric vs. Asymmetric Encryption

All encryption algorithms fall into two main types: symmetric (one key for encryption and decryption) and asymmetric (a pair of keys — public and private). The choice of type depends on the use case: symmetric algorithms are more often used for encrypting local data due to their speed, while asymmetric algorithms are used for key exchange and authentication.

In practice, mobile applications use hybrid encryption: an asymmetric algorithm (e.g., ECDH) is used for session key exchange, and all subsequent data is encrypted with a symmetric algorithm (AES or ChaCha20). This approach combines the speed of symmetric encryption with the security of asymmetric key exchange. This method is the foundation of TLS 1.3, the Signal Protocol, and Apple iMessage.

Main Encryption Algorithms

Modern mobile development uses several standardized encryption algorithms, each designed for specific tasks with its own area of application.

• AES (Advanced Encryption Standard) — a symmetric block cipher certified by NIST in 2001. It uses 128, 192, or 256-bit keys. The recommended mode is GCM (Galois/Counter Mode), which provides authenticated encryption. AES-256 is used in Android Keystore, iOS Keychain, and all modern TLS protocols.
• ChaCha20-Poly1305 — a symmetric stream cipher developed by Daniel Bernstein. It provides the same level of security as AES-256 but performs faster on devices without hardware AES acceleration (typical for budget Android smartphones). ChaCha20 is used in TLS 1.3 as an alternative to AES-GCM and is the primary cipher in the Signal Protocol.
• RSA (Rivest-Shamir-Adleman) — an asymmetric algorithm used for key encryption and digital signatures. The minimum recommended key size is 2048 bits. RSA is slower than ECDH, so it is being replaced by elliptic curve cryptography (ECC) in modern mobile applications.
• ECDH (Elliptic Curve Diffie-Hellman) — an asymmetric key exchange protocol based on elliptic curves. It provides Perfect Forward Secrecy and is used by default in TLS 1.3. The Curve25519 (X25519) curve is the most common in mobile applications.

How Encryption Protects User Data

Encryption protects data in three key scenarios: device loss (disk and app container encryption), traffic interception (TLS/HTTPS network protocols), and server-side leakage (end-to-end encryption). Each scenario requires its own approach and tools.

Data at Rest and Data in Transit

Data at rest — data on the device — is encrypted via Android Keystore and iOS Keychain. On Android starting from 7.0, File-Based Encryption is used, and apps can additionally encrypt their data through EncryptedSharedPreferences and EncryptedFile from the AndroidX Security library. On iOS, all apps work by default with the Data Protection API, which encrypts files at the file system level with a key tied to the device passcode. For data in transit, TLS 1.2/1.3 with mandatory Certificate Pinning is used.

End-to-End Encryption

End-to-end encryption (E2E) — the highest level of data protection, where a message is encrypted on the sender’s device and decrypted only on the recipient’s device. The storage and transmission server has no access to the content — it only handles encrypted blobs. The most well-known E2E implementation for mobile applications is the Signal Protocol, which uses the Double Ratchet Algorithm in combination with X3DH (Extended Triple Diffie-Hellman) for initial key exchange. The Signal Protocol provides Perfect Forward Secrecy and future secrecy: compromising one key does not reveal previous or subsequent messages. According to a study by Carnegie Mellon University (2023), E2E encryption in messaging apps reduces the risk of communication leakage by 99.7% compared to TLS-only encryption. E2E application is mandatory for Health & Fitness and Finance apps under GDPR and HIPAA requirements. To implement E2E in your own project, it is recommended to use the Signal Protocol library (Java/Swift) or one based on Olm (Matrix protocol). When choosing an E2E solution, evaluate platform compatibility: the Signal Protocol requires support for asynchronous sending and key storage on the client, which complicates multi-device scenarios — for such cases, the Matrix Protocol with its room model may be a better choice.

val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .build()

val encryptedFile = EncryptedFile.Builder(
    context,
    File(context.filesDir, "secret.dat"),
    masterKey,
    EncryptedFile.FileEncryptionScheme.AES256_GCM_HKDF_4KB
).build()

encryptedFile.openFileOutput(applicationContext).use { outputStream ->
    outputStream.write("Sensitive user data".toByteArray(Charsets.UTF_8))
}