AES or ChaCha20 on mobile platforms

My short answer: On modern iPhones and high-end Android devices, I usually choose AES-GCM. On older, budget, or mixed Android devices, ChaCha20-Poly1305 is often the better choice. Not because of “more security”, but because of speed, CPU load, heat, and battery.

If I boil the topic down to a simple rule, it’s this:

• AES-GCM fits well when AES hardware is available.
• ChaCha20-Poly1305 often fits better when AES runs only in software.
• Both are only secure if I never reuse nonces.
• I process data only after successful verification.
• For mobile apps, in the end, device class, local storage, transmission, keystore/keychain, and TLS 1.3 matter more than faith-based questions about the algorithm.

One point stands out: If AES runs without hardware, the effort can cost up to 10 times more CPU cycles per byte according to the article. On entry-level Android devices, ChaCha20 can be about 3× faster. You notice this with photo uploads, sync, messaging, and cache.

What I pay attention to:

• iOS / flagship Android: mostly AES-GCM
• Mid-range / older Android devices: often ChaCha20-Poly1305
• Local data: choice based on device class
• API usage data and messages: clean key and nonce management
• For all cases: Android Keystore, Apple Keychain, 96-bit nonce per operation, TLS 1.3, regular key rotation

In short: If I build an app for many Android classes, I want consistent performance. If I target new devices with AES hardware, AES-GCM is often my first choice.

The Modern Cipher Showdown: A Deep Dive into ChaCha20-Poly1305 vs. AES-GCM

sbb-itb-1cfd233

Quick Comparison

I summarize the article like this: Not "Which algorithm is better?" is the core question, but "On which device does my app run, and where is the data?"

AES-GCM vs. ChaCha20-Poly1305: How the two methods differ in mobile apps

In the end, it’s about three things: structure, hardware usage, and implementation errors. For mobile apps, the available hardware, runtime in software, and what happens if something goes wrong in implementation matter most in everyday use.

AES-GCM on Android and iOS

AES-GCM is an AEAD method based on AES. On devices with hardware acceleration, it works very fast. Without this support, performance often drops significantly.

ChaCha20-Poly1305 on Android and iOS

ChaCha20-Poly1305 is an AEAD method based on ChaCha20. It is designed for software execution and is therefore often advantageous on older or cheaper Android devices.

Security requirements shared by both methods

Both methods share the same critical point: A nonce must never be reused with the same key. If this happens, the security of both methods breaks down. With AES-GCM, even forgeries can become possible.

Equally important: Decrypted data must only be processed after successful authentication. In other words: verify first, then handle. Anything else is like locking the front door only after entering.

The next section shows how this affects speed and battery.

Speed and battery: Why device class makes the difference

On mobile devices, the device class makes the biggest difference. AES-GCM benefits greatly from hardware acceleration, while ChaCha20-Poly1305 stays fast even when everything runs in software. This is exactly where the gap between high-end, mid-range, and older devices becomes clear.

For apps with photos, messages, and auction updates, one thing matters most: How well do sync and encryption run on older smartphones? Because that’s where you notice delays, high CPU load, and drained batteries the fastest.

Modern iPhones and Android flagships

On current iPhones and high-end Android devices, AES-GCM is usually faster. The reason is simple: The hardware handles AES operations directly and achieves very high throughput. At the same time, CPU load, heat generation, and battery consumption stay low. This also makes performance more predictable across different Android devices.

Mid-range, older, and entry-level Android devices

Many older or cheap Android devices without ARMv8 crypto extensions have to run AES entirely in software. This costs noticeably more processing time: Software AES can consume up to 10 times more CPU cycles per byte than hardware-accelerated AES. The device heats up faster, and the battery drains noticeably quicker.

ChaCha20-Poly1305 is designed for software execution and often clearly leads here. You notice this directly during syncs, photo uploads, and encrypted local data.

The table shows how much the device class can affect speed and battery.

All figures depend on benchmarks and vary by SoC and library implementation.

Running benchmarks correctly

A single speed value from a current test device is of little practical use. It’s more useful to specifically test on older devices that are still actively used.

Measure over 5–10 minutes under load:

• Throughput
• Latency
• Energy per byte

Also important: Use the same library on both platforms. Otherwise, you’re not comparing algorithms but just differences in implementation.

How much this matters for local data, images, and API calls is shown in the next section.

Offline storage and data transfer in marketplace apps

For Gunfinder, one thing is especially important: Are data stored locally or transmitted? That’s exactly where the risk lies and which protection measure brings more benefit.

Offline Storage: Databases, Cache, Drafts and Account and Profile Data

Locally stored data is often underestimated. Yet this is exactly where part of the problem lies. Stored search results, cart contents as well as account and profile data are directly on the device. If a backup is not protected or the device is compromised, this data can become accessible.

For local data, the target device is especially important. If the device has AES acceleration, AES-GCM is a strong choice. If this support is missing, ChaCha20-Poly1305 often runs more efficiently. The key should be securely stored in the Android Keystore or in the Apple Keychain or Secure Enclave. And one point is non-negotiable: Every file needs its own 96-bit nonce. Reusing a nonce breaks security and integrity.

The same basic principle applies to transmissions. However, the focus there is in a different place: on payload and logging.

Data Transmission: API Calls, Image Uploads, Messages and Auction Updates

TLS protects the transport path. But that does not automatically mean that the payload itself is protected. If private messages between buyers and sellers or bid data in auctions end up in server logs, they are readable in plaintext without additional encryption at the app level. This is exactly where AES-GCM and ChaCha20-Poly1305 come into play. They complement transport encryption as a second layer of protection.

The key point is therefore not primarily the algorithm. What matters is whether data is on the device or traveling through the network.

What Matters More Than the Cipher Choice

For local data, the device class is the main point. For API payloads, uploads and messages, clean key and nonce management is especially important.

For Gunfinder, what counts in the end is exactly this: clean key and nonce management. Which variant fits better in everyday use is shown in the next section.

Decision Aid and Conclusion for Gunfinder Apps

For Gunfinder, one thing is especially important: Which device is using the app and what data is being processed? This is exactly what determines the choice of method in practice. The table below sums it up and classifies typical Gunfinder workflows.

The same basic framework applies for all cases: secure key storage via Android Keystore or Apple Keychain, unique nonces per operation, TLS 1.3 for every transmission, and regular key rotation. Without these points, even the best algorithm only helps halfway.

When AES-GCM is the better choice

AES-GCM fits well with modern iPhones and flagship Android devices when AES hardware is available and the backend already relies on it. Then the method plays to its strengths where the devices directly support it well.

When ChaCha20-Poly1305 is the better choice

As soon as older or cheaper Android devices come into play, ChaCha20-Poly1305 is often the more reliable choice. The reason is simple: performance usually remains more consistent on such devices than with software AES.

The key takeaways

Both algorithms are secure when used properly. In short: AES-GCM fits well in hardware-heavy environments, ChaCha20-Poly1305 rather in mixed Android fleets.

FAQs

How do I know if my target device has AES hardware?

Whether your target device has AES hardware acceleration depends on the installed CPU. Many newer processors support AES-NI. This makes encryption significantly more efficient.

For Android and iOS devices, you best check this in the processor’s technical specifications. On ARM-based smartphones and tablets, hardware acceleration for cryptographic operations is often already built in. The operating system usually uses it automatically.

What happens with nonce reuse?

If you use a nonce more than once, you undermine the security of the encryption.

Attackers can then see patterns in the encrypted data or even draw conclusions about the key used.

This hits the confidentiality of your data hard. Therefore, the nonce must be new and unique for every encryption operation.

Is TLS 1.3 enough without additional app encryption?

No. TLS 1.3 protects data during transmission. It does not cover locally stored app data on the device.

If you want to protect data end-to-end, you therefore also need local encryption. For sensitive transactions, AES-256 can also make sense.

Only the combination of secure transmission and local encryption helps even when there are technical problems or someone gains unauthorized access to the device.

Related Blog Posts

• Overview: Encryption Standards in E-Commerce
• How Audits Improve Encryption Security
• Reliability of Biometric Systems: What Hunters Need to Know
• Encryption Technologies Overview: Security and Performance