For most applications either AES-GCM or ChaCha20-Poly1305 is a sound choice, and the better pick is whichever your vetted library offers with the safest interface. Nonce handling matters more than the algorithm name: both fail badly if a nonce repeats under the same key.
What they have in common
Both are AEAD ciphers: they encrypt and authenticate in one operation, and they let you bind extra data such as a header or record ID that is authenticated but not encrypted. OWASP's cryptographic storage guidance says authenticated modes should always be used where available, with GCM and CCM listed first.
Both take a 256-bit key in their strongest form. RFC 8439 specifies ChaCha20-Poly1305 with a 256-bit key, a 96-bit nonce and a 128-bit tag, and says the tag must not be truncated.
Where they differ in practice
- Hardware. AES is fast where the CPU has AES instructions, which covers most servers and recent phones. ChaCha20 is designed to be fast in plain software, which helps on devices without those instructions.
- Library defaults. Pick the one your platform crypto library exposes as a high-level, hard-to-misuse call.
- Compliance. If you must meet a standard that lists approved algorithms, AES is the one that usually appears. Check the specific requirement instead of assuming.
- Nonce handling. Both use a 96-bit nonce in common forms, so random nonces start to collide at high volume under one key. Plan how you will generate nonces.
The nonce rule
RFC 8439 states that if a nonce repeats, both the one-time Poly1305 key and the keystream are identical between the two messages, so an observer can compute the XOR of the plaintexts. For AES-GCM a repeated nonce is similarly severe. Our post on AES-GCM nonce reuse and key usage limits goes into the numbers.
Practical options:
- Use a counter per key, if you can keep it safe across restarts and replicas.
- Use random nonces and rotate the key before the message count gets large.
- Use a library that offers a misuse-resistant or extended-nonce variant, if one fits your case.
A simple decision rule
- Does your library give a single safe call for one of them? Use that one.
- Are you on constrained devices without AES hardware? Lean to ChaCha20-Poly1305.
- Are you under a compliance list? Check whether it names AES.
- Are you encrypting a huge number of small messages under one key? Think hard about nonce strategy before anything else.
Quick check
Is AES-CBC with a hash fine instead?
It can be, if done as encrypt-then-MAC with separate keys, but it is easy to get wrong. An AEAD gives you the safe composition by default.
Do I need to store the nonce?
Yes, in most designs. It is not secret, so store or send it next to the ciphertext.
Sources
Last reviewed: 19 October 2026.
