Some months ago, we discovered that a cause of slower response times from the API is the algorithm used to decrypt the API key on each request. Currently, argon2 is used, which is quite expensive and unnecessarily strict for an API key (it is a better match for user passwords, which are much shorter and weaker i.e. could be guessed / brute-forced).
Using i.e. SHA256, as Tiled does, would be more appropriate and would improve response times.
Granted, this is not as much of a problem now that the API has been scaled up both horizontally and vertically. Before scaling, this was causing massive slowdowns (seconds scale) whereas that is not the case anymore.
Still, argon2 is intentionally slow, and appears to impose unnecessary cost to responses. Based on past benchmarks, the /proposals/data-sessions endpoint took ~60ms without encryption BEFORE the API was scaled. Now, with encryption and AFTER scaling, it takes 200ms. Using SHA256 I suspect would get a 4x improvement.
Old threads for reference (1, 2)
I also talked to SC about this at the end of last year, from my notes:
Got to chat with SC today. There isn't any policy reason for argon2 in nsls2api. He chose it in case there was ever a need to encrypt shorter keys, it would already be there. We could rip it out and replace it for API keys.
Some months ago, we discovered that a cause of slower response times from the API is the algorithm used to decrypt the API key on each request. Currently,
argon2is used, which is quite expensive and unnecessarily strict for an API key (it is a better match for user passwords, which are much shorter and weaker i.e. could be guessed / brute-forced).Using i.e.
SHA256, as Tiled does, would be more appropriate and would improve response times.Granted, this is not as much of a problem now that the API has been scaled up both horizontally and vertically. Before scaling, this was causing massive slowdowns (seconds scale) whereas that is not the case anymore.
Still,
argon2is intentionally slow, and appears to impose unnecessary cost to responses. Based on past benchmarks, the/proposals/data-sessionsendpoint took ~60ms without encryption BEFORE the API was scaled. Now, with encryption and AFTER scaling, it takes 200ms. UsingSHA256I suspect would get a 4x improvement.Old threads for reference (1, 2)
I also talked to SC about this at the end of last year, from my notes: