The first draft (current as of v0.2 of this repository) defined four purposes:
Shared-key Authentication (auth)
Shared-key Encryption (enc)
Public-key Authentication (sign)
Public-key Encryption (seal)
However, seal has since been removed due to a lack of a good real-world use case.
I've been discussing this with other crypto/security experts, and I think we might be able to get the same utility out of PAST if we dropped auth, and changed our paradigm to look like this:
Shared-key AEAD (local)
Digital signatures (public)
If you need the equivalent use-case of v2.auth (e.g. so you can inspect some data in the token before decoding/verifying it normally), you can simply encrypt an empty string and append your public data in the footer.
This would simplify our design, reduce our technical debt, and minimize the attack surface to a reasonable level. However, this is also a secure-by-default feature: If you're just storing data in a token and using the user as a data mule for local usage, it won't be plaintext.
The first draft (current as of v0.2 of this repository) defined four purposes:
auth)enc)sign)seal)However,
sealhas since been removed due to a lack of a good real-world use case.I've been discussing this with other crypto/security experts, and I think we might be able to get the same utility out of PAST if we dropped
auth, and changed our paradigm to look like this:local)public)If you need the equivalent use-case of
v2.auth(e.g. so you can inspect some data in the token before decoding/verifying it normally), you can simply encrypt an empty string and append your public data in the footer.This would simplify our design, reduce our technical debt, and minimize the attack surface to a reasonable level. However, this is also a secure-by-default feature: If you're just storing data in a token and using the user as a data mule for local usage, it won't be plaintext.