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
| 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.dylibis 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/iatclaims, footers, and PASERK key IDs. - No system library dependency. Uses
cryptography(bundles OpenSSL) andpycryptodomex. 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, andiso8601. Overkill if you only need v4.public sign/verify. - Abstraction layer. The
Keyobject andPasetoclass 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.