b2KIT

ChaCha20-Poly1305 Encryption

Encrypt and decrypt data using ChaCha20-Poly1305 AEAD cipher with authenticated encryption and nonce management.

Tested tool guide Tested browser tools Checked August 16, 2026

What ChaCha20-Poly1305 Encryption does and how it behaves

ChaCha20-Poly1305 Encryption converts plaintext into authenticated ciphertext, or verifies and decrypts an existing result. The operation combines ChaCha20 encryption with a Poly1305 authentication tag, using a 256-bit key and a 96-bit nonce. The common mistake is treating the nonce as an optional random decoration. It need not be secret, but it must not be reused with the same key. Because keys and plaintext are sensitive, performing the operation entirely in the browser also avoids uploading them.

How the result is produced

1

Encryption inputs

Encryption uses a 32-byte secret key and a 12-byte nonce. ChaCha20 transforms the plaintext into ciphertext, while Poly1305 produces a 16-byte authentication tag. The result therefore includes both encrypted bytes and evidence that the ciphertext has not been altered. Displayed text may be encoded as hexadecimal or Base64, which is a representation of the bytes rather than additional encryption.

2

Authenticated decryption

Decryption requires the original key and nonce together with the complete ciphertext and authentication tag. If associated data was included during encryption, the identical bytes must also be supplied. A changed key, nonce, ciphertext, tag, or associated-data value causes authentication to fail. Plaintext from a failed verification must not be treated as valid.

Good uses

  • Encrypt a short message while retaining a tag that can detect later modification.
  • Decrypt and verify a ChaCha20-Poly1305 test value when its key, nonce, ciphertext, and tag are available.
  • Compare how changing one nonce or plaintext byte changes the authenticated ciphertext for protocol debugging.

Limits and checks

  • Never reuse a nonce with the same key. The nonce may be stored beside the ciphertext, but uniqueness under that key is essential.
  • Hexadecimal and Base64 values can represent identical bytes while looking different. Confirm the expected encoding before comparing results or copying fields.
  • A password is not necessarily a valid encryption key. If a field expects 32 key bytes, a password needs an appropriate, separately specified key-derivation process.

Common questions

Can I decrypt the data without the original nonce?

No. ChaCha20-Poly1305 decryption needs the same nonce used for encryption, as well as the correct key, ciphertext, tag, and any associated data. The nonce does not need confidentiality, so it is normally retained with the encrypted result. Guessing a missing 96-bit nonce is not a practical recovery method.

Why does decryption report an authentication failure?

At least one required byte differs from the encryption inputs. Check the key, nonce, ciphertext, authentication tag, associated data, and their encodings. Even a one-bit change should make verification fail. Authentication failure does not identify which field is wrong, and there is no valid partial plaintext to accept from that result.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools