PASETO v2 vs v4 — What Changed

PASETO v2 and v4 are both modern, non-NIST PASETO versions and share the same conceptual structure (XChaCha-family for local, Ed25519 for public). v4 is the current recommended default; v2 is now considered legacy.

What's the same:

Both v2 and v4 use Ed25519 signatures for public tokens — so the signature size, security level, and verification workflow are essentially identical. Both are non-FIPS, both target the same modern threat model (no algorithm negotiation, AEAD-only), and both are widely supported in PASETO libraries.

What changed in v4:

The biggest change is in the local variant. v2.local uses XChaCha20-Poly1305 (a single AEAD construction), while v4.local uses XChaCha20 for encryption with a separate BLAKE2b keyed-hash for authentication. This split-construction approach matches the design of NaCl's secretbox and gives PASETO authors more flexibility to evolve each primitive independently. v4 also tightened the pre-authentication encoding (PAE) format slightly to reduce ambiguity.

Performance:

In practice, v4.local is comparable to or slightly faster than v2.local on most platforms because BLAKE2b is highly optimized. v4.public and v2.public are essentially identical in performance — Ed25519 signing/verifying dominates either way.

Migration:

If you're starting a new system, choose v4. If you have an existing v2 deployment, you don't need to migrate urgently — v2 isn't broken, just superseded. A typical migration path is to issue both v2 and v4 tokens during a transition window, accept either on the verifier side, then stop issuing v2 once all clients have rotated. Don't try to convert tokens in place — re-issue them through the normal authentication flow.

v3 sits between them:

v3 was added specifically for environments that require NIST-approved primitives (FIPS 140-2/3 compliance). Use v3 only if you have that requirement; otherwise v4 is the better choice.