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

What happened? The performance of jsonwebtoken 9.0.2 is 50 times slower than 8.5.1 #966

Open
VxRain opened this issue Apr 11, 2024 · 4 comments

Comments

@VxRain
Copy link

VxRain commented Apr 11, 2024

Description

The performance of jsonwebtoken 9.0.2 is 50 times slower than 8.5.1, mainly in the HS256 algorithm.
The encoding speed has slowed down by 53 times, and the decoding speed by 34 times.

8.5.1 benchmark results

Encoding
HS256 x 120,423 ops/sec ±0.33% (91 runs sampled)
RS256 x 793 ops/sec ±0.50% (94 runs sampled)
ES256 x 2,418 ops/sec ±0.99% (94 runs sampled)
Fastest encoder is HS256

Decoding
HS256 x 87,990 ops/sec ±0.93% (95 runs sampled)
RS256 x 5,921 ops/sec ±0.89% (93 runs sampled)
ES256 x 4,763 ops/sec ±0.77% (94 runs sampled)
Fastest decoder is HS256


9.0.2 benchmark results

Encoding
HS256 x 2,264 ops/sec ±4.58% (78 runs sampled)
RS256 x 759 ops/sec ±0.73% (93 runs sampled)
ES256 x 2,131 ops/sec ±1.08% (91 runs sampled)
Fastest encoder is HS256

Decoding
HS256 x 2,568 ops/sec ±0.93% (93 runs sampled)
RS256 x 5,527 ops/sec ±1.60% (87 runs sampled)
ES256 x 3,871 ops/sec ±1.62% (91 runs sampled)
Fastest decoder is RS256

Reproduction

https://github.com/VxRain/node-jwt-benchmark

Environment

  • Node: v20.12.2
  • System: Win11
  • CPU: AMD R7 5800H
@panga
Copy link

panga commented Apr 15, 2024

Confirmed the performance regression.

Looks like it was introduced in ecdf6cc by adding a crypto.createSecretKey call to create a KeyObject instead of using the string secret or PEM file. This was done to address some security vulnerabilities.

The regression can be workaround in 9.0.2 by passing a KeyObject directly to sign/verify methods.

@panva
Copy link
Contributor

panva commented Oct 3, 2024

I strongly suggest passing any key material as KeyObject instances.

This is especially beneficial for HMAC based algorithms since it avoids the library having to guess what type of key (or secret) is passed.

const secret = crypto.createSecretKey(Buffer.from('your secret'))

@panva
Copy link
Contributor

panva commented Oct 3, 2024

See the difference when KeyObject is used. secret with crypto.createSecretKey, public keys with crypto.createPublicKey, private keys with crypto.createPrivateKey

Before:

Signing
HS256 x 3,945 ops/sec ±1.07% (98 runs sampled)
RS256 x 892 ops/sec ±1.86% (99 runs sampled)
ES256 x 3,286 ops/sec ±1.08% (97 runs sampled)

Verification
HS256 x 3,809 ops/sec ±0.67% (96 runs sampled)
RS256 x 9,239 ops/sec ±0.83% (97 runs sampled)
ES256 x 6,234 ops/sec ±1.62% (95 runs sampled)

After:

Signing
HS256 x 249,222 ops/sec ±0.83% (94 runs sampled)
RS256 x 1,741 ops/sec ±0.86% (100 runs sampled)
ES256 x 36,444 ops/sec ±0.90% (93 runs sampled)

Verification
HS256 x 186,174 ops/sec ±0.38% (95 runs sampled)
RS256 x 43,935 ops/sec ±0.59% (100 runs sampled)
ES256 x 16,091 ops/sec ±0.67% (99 runs sampled)

@panva
Copy link
Contributor

panva commented Oct 3, 2024

@frederikprijck let's figure out how to change the docs to indicate the inputs SHOULD be KeyObject instances and that other means of passing key material are strictly for convenience.

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

3 participants