Consider switching to more efficient encryption 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, 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.

Start by locating the API-key decryption path and the /proposals/data-sessions endpoint. Compare the current argon2 cost with the proposed SHA256 approach, including the security implications and compatibility requirements. Done means an agreed algorithm change with benchmark evidence showing improved response time without weakening the intended API-key protection.