AES: What It Is, Symmetric Encryption Algorithm and Where It's Used

AES Key Sizes and Security Levels

AES supports three key sizes, each corresponding to a specific cryptographic strength level. Key size choice affects security, performance, and device resource requirements.

Practical rule: for mobile applications use AES-256 by default. The performance difference between AES-128 and AES-256 on modern devices with AES-NI support is no more than 10–15%, but the security level doubles. According to quantum analysis (Grassl et al., 2016), cracking AES-128 would require 2^77 quantum operations via Grover's algorithm, while AES-256 would require 2^149, making AES-256 resistant to quantum attacks for the next 20–30 years. Even AES-128 provides sufficient protection for the vast majority of commercial scenarios: brute-forcing a 128-bit key would require more energy than exists in the universe according to Bruce Schneier's estimate. However, security standards (GDPR, HIPAA, PCI DSS) often explicitly require AES-256, so production projects should use the maximum key length.

AES Operation Modes

AES as a block cipher encrypts fixed-size blocks (128 bits). For encrypting arbitrary-length data, operation modes are used. Mode selection critically affects security: the wrong mode can negate AES strength.

• ECB (Electronic Codebook) — the simplest and most insecure mode. Each block is encrypted independently with the same key. Identical plaintext blocks produce identical ciphertext blocks, allowing data structure recovery. Prohibited in all modern security standards. NEVER use ECB in mobile applications.
• CBC (Cipher Block Chaining) — each previous ciphertext block is used as an initialization vector (IV) for the next one. Requires a random IV for each message. Vulnerable to padding oracle attacks when improperly implemented. Suitable for file encryption but requires MAC (HMAC) for data integrity.
• GCM (Galois/Counter Mode) — the recommended mode for mobile applications. Provides authenticated encryption (AEAD): encryption + integrity verification in a single operation. Uses a counter for keystream generation and Galois field multiplication for authentication. GCM requires a unique nonce (12 bytes) for each message. Recommended by NIST, used in TLS 1.2/1.3 and Android Keystore.
• CCM (Counter with CBC-MAC) — an alternative AEAD mode based on CTR + CBC-MAC. Slower than GCM and does not support parallel processing. Used in ZigBee and 802.11 (Wi-Fi) protocols. For mobile applications, GCM is preferred.

For mobile projects use AES-256-GCM with a 12-byte nonce. GCM solves two problems simultaneously: data encryption and authentication, preventing padding oracle and chosen ciphertext attacks. Android Keystore and iOS CryptoKit support AES-GCM out of the box without needing additional cryptographic primitives. When working with GCM, it is critical to never reuse a nonce with the same key — this completely destroys encryption security. Generate a new random nonce for each encryption and store it alongside the ciphertext.

Implementing AES in Mobile Applications

Let's look at an example of secure AES-256-GCM implementation on Android using Jetpack Security. The code below demonstrates the full cycle: creating an AES-256 key via MasterKey, encrypting and decrypting a string with additional authenticated data (AAD).

import androidx.security.crypto.MasterKey
import androidx.security.crypto.EncryptedSharedPreferences

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

val securePrefs = EncryptedSharedPreferences.create(
    context,
    "secure_prefs",
    masterKey,
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)

fun storeSecureData(key: String, value: String) {
    securePrefs.edit().putString(key, value).apply()
}

fun readSecureData(key: String): String? {
    return securePrefs.getString(key, null)
}

The key feature of this solution is that AES-256-GCM is used at two levels: for encrypting key-value pairs (PrefValueEncryptionScheme) and for protecting the key names themselves (PrefKeyEncryptionScheme uses AES-256-SIV, resistant to nonce reuse). MasterKey is generated using the AES-256-GCM algorithm and stored in Android Keystore, which is hardware-protected on devices with Trusted Execution Environment. On devices without hardware support (TEE), the key is encrypted via Bouncy Castle, which is still safer than storing in SharedPreferences.

For direct encryption of large data volumes (e.g., images or files), use AES-256-GCM via EncryptedFile from AndroidX Security. For key export (e.g., for backup), use additional encryption with a user password via PBKDF2 with 100000+ iterations.

AES on iOS via CryptoKit

On iOS, AES operations are organized through the CryptoKit framework (Swift 5.0+). An AES-256 key is created via SymmetricKey(size: .bits256) and stored in the Secure Enclave — a hardware crypto processor isolated from the main CPU and operating system. CryptoKit provides two AES implementations: AES.GCM (recommended) and AES.CBC (for backward compatibility with legacy formats). Encryption is performed via the seal() method, which takes data, key, and nonce (12 bytes), and returns AES.GCM.SealedBox — a structure containing ciphertext and authentication tag. Decryption is via open(). Apple strongly recommends against using CommonCrypto directly: CryptoKit automatically selects optimal parameters, protects against side-channel attacks, and uses AES-NI hardware acceleration on Apple Silicon processors. On devices with Secure Enclave, keys never leave the hardware module, preventing theft even with full application compromise. For key serialization, use the withUnsafeBytes method followed by storage in Keychain via SecItemAdd with the kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly attribute.