Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider switching to blake2 #51

Closed
aaugustin opened this issue May 14, 2020 · 1 comment
Closed

Consider switching to blake2 #51

aaugustin opened this issue May 14, 2020 · 1 comment

Comments

@aaugustin
Copy link
Owner

Suggested by Florian Apolloner:

If you are changing the algorithm, I'd probably switch over to blake2, especially because you can choose the size of your output with the digest_size argument.

While there's no version number in tokens, since the token format is <URL-safe Base64 encoded data>:<signature>, it's possible to adding a version number in the payload, using a URL-safe character outside of the URL-safe Base64 alphabet as a delimiter. If this character is present in the payload, then it's the new version. If not, it's the old version. RFC 2396 says our options are "." | "!" | "~" | "*" | "'" | "(" | ")" (since "-" | "_" are already taken).

Per the Cryptographic Doom Principle, the version number should be in the payload, so it's included in the signature. Something like <URL-safe Base64 encoded data>:<version>:<signature> would be a bad idea.

@aaugustin
Copy link
Owner Author

I didn't do exactly what I said above, but I did take advantage of Blake2 in #53.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant