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

Asymmetric JWTs? #95

Closed
grahamc opened this issue Nov 7, 2023 · 6 comments
Closed

Asymmetric JWTs? #95

grahamc opened this issue Nov 7, 2023 · 6 comments

Comments

@grahamc
Copy link
Contributor

grahamc commented Nov 7, 2023

Would you be interested in a patch to make attic's JWTs switch to RS256, which is an asymmetric publ/priv key for signing / validating?

@cole-h
Copy link
Collaborator

cole-h commented Nov 12, 2023

The PR is up: #99.

@apexo
Copy link

apexo commented Sep 24, 2024

But the question is: why? What is the advantage here? RS256 JWTs might make sense in a scenario where the creation and consumption of JWT tokens is decoupled. Here, where that is not the case, it only adds complexity. The asymetric crypto operations are inherently more complex (more code, bigger binary size, more possibilities for bugs) and slower.

@fd
Copy link

fd commented Oct 2, 2024

Generally asymmetric keys are much safer than a single symmetric key. Additionally asymmetric keys enable more complex deployments where tokens are generated by another service based on per-device credentials (like hashicorp Vault).

@apexo
Copy link

apexo commented Oct 3, 2024

Generally asymmetric keys are much safer than a single symmetric key.

That is true if encryption/decryption or signing/verification happen in different places. Then you need the private key only for signing/decryption and encryption/verification can use the public key. That means the secret has two only be in one place, not in two places.

In the context where we only have a single instance of attic, which does both: signing and verification of JWT tokens, you don't gain anything by using asymmetric crypto. There are losses though: crypto operations are slower, and setting up a public/private key pair is more complicated than using a symmetric key.

I agree that for more complex deployments you may want to use asymmetric crypto.

For speed, how bad is it? According to some random benchmark I found RS256 verification is may 5x slower than HS256. I can imagine scenarios (many small requests) where this would lead to a significant increase in CPU usage.

In a scenario where few users are doing many requests, you could alleviate some of the performance loss by e.g. caching (a limited number of) hashes of already verified JWT tokens.

Otherwise, maybe people should have a choice between RS256 and HS256 🤷

@fd
Copy link

fd commented Oct 3, 2024

For speed, how bad is it? According to some random benchmark I found RS256 verification is may 5x slower than HS256. I can imagine scenarios (many small requests) where this would lead to a significant increase in CPU usage.

Slower is rarely a good argument for accepting less secure setups, We are talking milliseconds here. Database lookups are in the order of 10's-100's of milliseconds at best. So performance is not a blocking issue here. On top of that, the verification step for asymmetrics keys is very fast. The sign step is generally slower (again, milliseconds). Signing happens way less then verifying. The take-away here is that asymmetric crypto is just fine.

Additionally RS256 support doesn't prevent HS256 support. If you want to use HS256, that's fine, and it will work. That should not prevent other people from using different algos. JWT/JWK has pretty good support for differentiation here.

@apexo
Copy link

apexo commented Oct 6, 2024

Database lookups are in the order of 10's-100's of milliseconds

You're comparing network latency and CPU load.

Well, the PR (#177) was merged, and it seems like there's still the choice to use HS256. So I guess all is good. Let's close this issue.

@cole-h cole-h closed this as completed Oct 7, 2024
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

Successfully merging a pull request may close this issue.

4 participants