ChaCha20-Poly1305 Cipher (RFC 8439)

Because counter 0 is spent making the Poly1305 key. The AEAD calls the ChaCha20 block function once with a counter of zero and takes the first 32 bytes of that block as a one-time authentication key, then encrypts the plaintext with the stream starting at counter 1. An implementation that starts the data at 0 is self-consistent and interoperates with nothing.

Two messages under one key and nonce give an attacker the XOR of the plaintexts, which is often enough on its own. Worse, both messages share the same one-time Poly1305 key, and seeing two valid tags under one such key is enough to recover it — after which the attacker can forge tags for messages of their choosing. This is not a degradation, it is a break, and it is why the tool warns.

Without them the boundary between the additional data and the ciphertext is ambiguous, and an attacker can move bytes from one to the other while keeping the tag valid. The construction appends the AAD length and the ciphertext length as 64-bit little-endian integers, after padding each of the two parts to a multiple of 16, precisely to pin that boundary down.

Both are AEADs with a 16-byte tag and a 12-byte nonce, and both fail catastrophically on nonce reuse. AES-GCM is faster where AES instructions exist and slower and more side-channel-prone where they do not; ChaCha20-Poly1305 is uniformly quick in software and has no table lookups. GCM also degrades if you truncate its tag, while Poly1305 has one tag length. For new protocols either is defensible; on mobile and embedded targets ChaCha20-Poly1305 usually wins.

The arithmetic is checked against every test vector in RFC 8439 and against a second implementation, but that is not the same as being safe to deploy. It runs in a browser tab, in JavaScript, with no constant-time guarantees and with your key in a text field and in this page’s local storage. Use it to check an implementation or to understand the construction, and use a reviewed library for anything that matters.