Releases: paragonie/paseto
Version 1.0.1
paragonie-security
P.I.E. Security Team
- Fix #74, which rendered a unit test useless (and the test in question was failing).
Version 1.0.0
paragonie-security
P.I.E. Security Team
It turns out, we don't need permission from the IETF to use PASETO in the real world (i.e. OAuth2). This is fortunate, because it's unlikely for them to accept a JWT alternative in the first place, no matter how doomed their christened standard may be.
Based on the feedback we've already received from security and cryptography experts around the world, this is simple and usable enough to use in the real world. So there's no point in delaying a stable release any further.
The documentation and reference implementation has been updated with some feedback from the RFC review process (i.e. optional footer handling).
Protocol changes:
None. We're quite happy with the way Paseto is currently designed.
PHP Library Changes:
- If you pass a footer to the third argument, it will be evaluated with strict constant-time equality. Otherwise, it will strip it off the token and decoded from base64.
Documentation Changes:
- Handling optional footers is less strict, as per RFC draft feedback.
Version 0.7.0 (a.k.a. 1.0.0-rc1)
paragonie-security
P.I.E. Security Team
We've completed draft-00 of our proposed RFC. This makes us one step closer to tagging v1.0.0.
Protocol changes:
None. We're quite happy with the way Paseto is currently designed.
PHP Library Changes:
- Use
setSignatureMode()instead ofsetEncryptionMode()for Version1. The end result was the same, but it's important to be explicit about our intent in our implementation.
Version 0.6.0
paragonie-security
P.I.E. Security Team
Protocol changes:
None. We're quite happy with the way Paseto is currently designed.
PHP Library Changes:
- A lot of mostly-internal type-safety work done by @aidantwoods
- Fixed: A footer of
0would not append to the token due to PHP's treatment of falsy values.
- Fixed: A footer of
- We explicitly tell phpseclib to use e = 65537 for version 1.
Other Changes:
- A lot of documentation has been fleshed out. Give it a read here: https://github.com/paragonie/paseto/tree/master/docs
- Several people have begun developing PASETO implementations in other programming languages. See all of them here.
Version 0.5.0
paragonie-security
P.I.E. Security Team
Special thanks to @aidantwoods for contributing a lot to this minor release.
Protocol changes:
None. We're quite happy with the way Paseto is currently designed.
PHP Library Changes:
- JsonToken building was split out into a separate
Builderclass, to make key management easier to reason about. - Instead of a string constant containing a header, the version object itself is expected in a few places.
- Purpose is now passed as an object rather than a string.
Version 0.4.0
paragonie-security
P.I.E. Security Team
Biggest change: We've changed our name from PAST to Paseto. It should be easier to find in a Google search.
Other fixes since v0.3.0:
- The HKDF constants have been updated to reflect the name change, and our test vectors use a full ISO 8601 DateTime string (including timezone).
- #26 was fixed with our reference implementation.
This may be our last pre-1.0.0 release. The only thing left to do (barring the discovery of any cryptography flaws unique to Paseto) is documentation work, including drafting an RFC to submit to the IETF.
Version 0.3.0
paragonie-security
P.I.E. Security Team
A lot has changed since v0.2.0! PAST is now a lot faster, simpler, and has a greater degree of misuse resistance.
sealhas been removed.authhas been removed.enchas been renamed tolocal.signhas been renamed topublic.- We now use unpadded base64url encoding.
- For encryption, nonces are now derived from the plaintext in addition to the OS CSPRNG, using HMAC-SHA384 (version 1) or keyed BLAKE2b (version 2). This should mitigate the risk of nonce reuse on systems or programming languages with insecure RNGs.
- More unit tests.
- More documentation. It should now be straightforward to implement PAST in other languages.
Version 0.2.0
paragonie-security
P.I.E. Security Team
PAST now has a basic reference implementation and a first draft for the specification.
Notable change to the cryptography since v0.1.0: We now feed data into MACs and signature algorithms in such a way to minimize the risk of canonicalization attacks. Although no practical exploits are known for HMAC-SHA384 or Poly1305, simply concatenating different values together as one giant string seems like a needlessly cavalier design decision. Our new serialization format should effectively mitigate any risks.
We're going to take some time to accept feedback from the community, polish up the documentation, and request review from professional cryptographers.
Unless a game-over protocol flaw is discovered, the current implementation should be assumed stable enough to serve as a reference point for developing implementations in other programming languages. However, don't deploy this in production until v1.0.0 has been tagged and released.
Version 0.1.0
paragonie-security
P.I.E. Security Team
The cryptography proof-of-concept is implemented. The remainder of the work is:
- Documentation
- Specification
- User Experience Design
- API Design
- Making Formerly-JOSE-Users Happy with their Use Cases
- (Unless they needed algorithm agility, in which case... No.)