PASETO v3.public — ECDSA P-384 and FIPS

v3.public was added to PASETO specifically to support deployments that need NIST-approved primitives — typically driven by FIPS 140-2/3 compliance requirements rather than purely by security.

Cryptography:

v3.public uses ECDSA over P-384 (secp384r1) with deterministic nonces (RFC 6979) for signatures. The signature is 96 bytes (raw R||S, two 48-byte field elements). Hashing is SHA-384.

Why P-384 instead of P-256:

The PASETO designers picked P-384 deliberately to provide a security margin above what JWT typically uses (ES256 is JWT's P-256 ECDSA). 192-bit security strength matches what Ed25519 offers in v4 — this is intentional, so migrating between v3 and v4 is a primitive swap, not a security level change.

Performance vs v4:

Ed25519 (v4) signing and verification are 2-5x faster than ECDSA P-384 (v3) in pure-software implementations. If you have hardware acceleration (HSM, TPM) for ECDSA, v3 may actually be faster. Otherwise, v4 wins.

FIPS implications:

Ed25519 was approved by NIST as part of FIPS 186-5 in 2023, so the historical "FIPS forces you to ECDSA" argument is weakening. However, getting your specific cryptographic library validated against FIPS 140-3 takes time, and many enterprise stacks still ship FIPS modules that only expose ECDSA. v3 will remain relevant for years for that reason.

Wire format:

v3.public.<base64url(payload || 96-byte-signature)>[.<base64url(footer)>]

The structure is identical to v4.public — just a different signature algorithm and length.

When to choose v3 over v4:

Choose v3 when (1) you must comply with FIPS 140-x using a validated module that doesn't ship Ed25519, (2) you're integrating with a partner who already standardized on P-384, or (3) you have specific hardware (HSM/TPM) that accelerates ECDSA but not Ed25519. Otherwise, v4 is the better default.