pyseto vs python-paseto: choosing a Python PASETO library

Two PyPI packages provide PASETO v4 support in Python. They share an identical low-level import path (from paseto.protocol.version4 import sign, verify, encrypt, decrypt, create_asymmetric_key, create_symmetric_key) but differ significantly in scope, dependencies, and maintenance posture.

The two packages

Attribute pyseto (pip install pyseto) python-paseto (pip install python-paseto) PyPI name pyseto python-paseto Import name pyseto (high-level) or paseto.* (low-level) paseto.* Current version 1.9.3 0.5.2 Python support >=3.10 >=3.10 PASETO versions v1, v2, v3, v4 v2, v4 only PASERK support Full (lid, sid, pid, local, secret, public, seal, wrap, pw) Minimal Crypto backend cryptography + pycryptodomex + argon2-cffi (no system lib needed) pysodium (requires system libsodium) High-level API Yes (pyseto.encode/pyseto.decode with Key objects, claim validation, serializers) No (low-level only; high-level described as future work since 2021) Maintenance Actively maintained through 2026. Migrated to uv/ruff, added trivy/pip-audit/actionlint/zizmor. Multiple releases per year. Last PyPI release Aug 2021. GitHub has dependabot/CI activity but no feature releases in ~5 years. GitHub stars ~104 ~27 Test vectors All official PASETO test vectors Official test vectors for v2/v4

Key tradeoffs

python-paseto strengths

Minimal, focused scope. Only v2 and v4, only low-level primitives. Thin wrapper over libsodium's Ed25519/XChaCha20.
Single runtime dependency (pysodium). Smaller install footprint if libsodium is already on the system.
Transparent crypto. Delegates directly to libsodium via pysodium's CFFI bindings. No key object abstraction layer.

python-paseto weaknesses

Requires system libsodium. Fails at import time if libsodium.so/libsodium.dylib is missing. Adds a deployment step that pure-Python deps avoid.
No v3 support. If you ever need NIST P-384/FIPS compliance, you must switch libraries.
Stale. 0.5.2 since Aug 2021. The "high-level API coming soon" note has been in the README for five years.
No PASERK. No key serialization, wrapping, password-based encryption, or key ID generation.

pyseto strengths

Complete PASETO/PASERK implementation. All four versions, all PASERK types including seal, wrap, and password-based key encryption.
High-level API with claim handling. pyseto.encode()/pyseto.decode() handle JSON serialization, exp/iat claims, footers, and PASERK key IDs.
No system library dependency. Uses cryptography (bundles OpenSSL) and pycryptodomex. pip install just works everywhere.
Actively maintained with modern tooling and security scanning in CI.

pyseto weaknesses

Heavier dependency tree. Pulls in cryptography, pycryptodomex, argon2-cffi, and iso8601. Overkill if you only need v4.public sign/verify.
Abstraction layer. The Key object and Paseto class add indirection that the low-level use case does not need.

API compatibility note

Both packages install a paseto Python package with the same module structure (paseto.protocol.version4). They conflict at install time -- you cannot have both in the same virtualenv. The low-level function signatures (sign, verify, encrypt, decrypt, create_asymmetric_key, create_symmetric_key) are compatible for v4, so switching between them requires only changing the pip dependency, not the application code.

Recommendation

For new projects: use pyseto. Actively maintained, covers the full spec, no system library requirement, high-level API prevents common mistakes (missing exp validation, footer handling).

For existing projects on python-paseto: no urgent migration needed if you only use v4 and the low-level API. The crypto is sound (it's libsodium). But be aware you're pinned to a library with no releases since 2021, and if you ever need PASERK, v3, or claim validation, you'll need to switch.