ChaCha20 Encryption

The result is six dot-separated fields on a single line, starting CTC1: the marker, the key derivation cost, and then the salt, nonce, authentication tag and ciphertext as Base64. The salt and nonce are freshly generated for every message, which is why encrypting the same text twice gives two different results. That is not noise in the output — it is what stops an observer from telling that two messages are the same, and what stops a reused nonce from leaking the relationship between them.

Because it is one line of ordinary characters, it survives being pasted through a chat window, a ticket, an email or a shell command without escaping. If your terminal wraps it across lines, the extra whitespace is ignored on the way back in.

Your passphrase is not used as the encryption key directly. It is run through PBKDF2-HMAC-SHA256 at 600,000 iterations with the per-message salt, producing the 32-byte key that ChaCha20 actually uses. The reason is that a passphrase is a low-entropy secret, and a key derived from it without any stretching can be attacked far faster than the encryption itself: an attacker testing candidate passphrases only has to repeat the derivation, not the cipher. Stretching makes each guess deliberately expensive, and the iteration count is stored in the envelope so it can be raised later without breaking anything already encrypted.

A bare stream cipher like ChaCha20 on its own gives you confidentiality and nothing else. Encrypt with the wrong key and you get a page of confident-looking rubbish with no way to tell it from the original, and someone who can alter the ciphertext can flip specific bits and change what your message says. Poly1305 fixes both. It computes a tag over the ciphertext that only verifies with the right key, so this tool can reject a bad passphrase, a truncated paste or a tampered envelope before showing you anything.

That is also why there is no "raw" mode here. It is possible to expose unauthenticated ChaCha20, but the failure mode is a wrong passphrase that looks like a successful decryption, and that is a trap rather than a feature.

This is symmetric encryption: the same passphrase both locks and unlocks. That means the passphrase has to travel to whoever needs to read the message, and if that channel is not secure the encryption buys much less than it appears to. There is also no recovery. Because the key is derived from the passphrase and the passphrase is never stored, an envelope whose passphrase is lost cannot be decrypted by anyone, including this tool.

Treat the passphrase like the message it protects. Do not put it in the same place as the envelope, and do not reuse one passphrase across messages that need to stay unrelated.

The browser has no ChaCha20 of its own — Web Crypto offers AES-GCM and nothing usable for this cipher — so the primitive is implemented directly in JavaScript and checked against the published RFC 8439 test vectors. That Poly1305 implementation uses BigInt rather than the usual array of 26-bit limbs, and the reason is worth stating plainly: the standard limb layout sums several products that reach roughly 2^57, which is past the point where JavaScript numbers stop being exact. In C that is harmless because integers are 64 bits wide, but in JavaScript it quietly produces a wrong tag for any message longer than one block while a single-block message still looks correct. One BigInt multiply per block is a fair price for an authenticator that is actually right.