4

I'm using Envoy as the gateway of my micro-service backend.

Envoy provides me the JWT mechanism, which means that with the help of a public key, Envoy can validate tokens generated with a private key.

It works as expected. However, my colleague just told me that this might has a bad performance because it's a heavy calculation to validate a token with a public key.

So is he right about the performance issue? If so, is there any method to improve the performance?

2 Answers 2

3

It depends a lot on the algorithm and key size you used, but yes, asymmetric signature validations do take much more compute than HMACs or similar. According to RSA verification time, you could expect about 100K clock cycles per RSA-2048 verification using a high-end CPU in 2014. Testing on a more modern CPU (Ryzen 9 5900X, mildly overclocked), I get 801501 2048 bits public RSA's in 10.00s, which is about 80,150/second/core (the test is single-threaded) on a modern CPU running at 4.89GHz (on the relevant core during the test; I checked). That's about 61 thousand cycles per verification on a modern CPU.

RSA-2048 isn't super strong, but should suffice for most JWTs. Running 4096-bit keys instead cuts the speed to barely over 1/4 as fast, 21918 operations/second/core.

In either case, you're probably fine. Even using RSA-4096, and a server CPU with barely over half the clock speed of my gaming rig, you're looking at more than 10K verifications per second on just one core. If your userbase is large enough that might begin to be a problem - if you get 100K requests per second, you'd need 10 cores (among however many machines you're using) just for JWT verification, which is definitely not ideal - but hardware is relatively cheap and this sort of thing parallelizes trivially. If 4096-bit is too slow, using 3072 or even 2048-bit keys will likely be fine (though the latter is considered to only be about 112 bits of entropy, which is low for a modern system; 3072 bit keys, considered to be about 128 bits of entropy, is definitely preferable).


There are other algorithms you could potentially use. Some JWT implementations only support RSA for asymmetric signatures, but many support other algorithms too.

Elliptic curve-based asymmetric cryptography not only uses far smaller keys than RSA, it's vastly faster at some operations. Unfortunately, it's not necessarily faster at signature verification, the thing you care about here. In fact, openssl speed ed25519 shows vastly faster signing speed than RSA, but only about 12,443 verifications per second per core on my CPU, substantially worse than RSA-4096. Since minting JWTs is much rarer than verifying them, you shouldn't worry too much about the signing speed, and focus on the verification.

With all that said: do you actually need asymmetric signatures at all? Generally, those are only desired when the issuer (the software that mints the JWTs) does not trust the verifier (the software which consumes the JWTs). That's very useful in some scenarios, like delegated authentication/authorization, but if you're minting the JWTs yourself on the same server that is verifying them then it's a total waste to use asymmetric signatures instead of HMACs. Even if the minting and verifying is done on different machines, depending on how much separation of trust there is, it might not matter whether they both know the same secret key. HMACs are hundreds of times faster compared to asymmetric signatures, even at much greater levels of entropy.

2

I don't think the performance penalty of validating a token using public key will be measurable when put together with the entire transaction. A database lookup will be orders of magnitude slower than a public key signature checking.

Usually an asymmetric cipher isn't used when you want to encrypt a large file because of performance: it's more efficient to create a random symmetric key, encrypt the file with this key, and encrypt the key with the public key. In this case, the entire transaction is the encryption, so any performance boost will massively improve the run time.

When just a small part of the transaction is the encryption or signature validation, increasing its performance tenfold will not impact the entire transaction time that much.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .