server

"The encrypted data along with the signature of the encrypted vote is written to the bigquery table (and not directly to the air-gapped server) which is written to another temp folder (only the account that has access permissions can write to this folder) before being downloaded and processed on air-gapped server." No, you say it is. From the client's side, all I do is POST my encrypted vote and signature ( https://github.com/VOTEism/server/blob/d8d3752af99d7f4c25c0b... ), encrypted with a public key I just got from an HTTP request to the same server, no? ( https://github.com/VOTEism/server/blob/d8d3752af99d7f4c25c0b... ). I can't tell what you're doing with it after that. And there's what may be an even worse issue (not even requiring tampering with the public key) - the user's signature appears to go outside of the encrypted blob. Now,

> https://github.com/VOTEism/server/blob/d8d3752af99d7f4c25c0b... Why fork threads only to immediately join on them? This is just sync code with extra context switching and fatter stack traces. > https://github.com/VOTEism/server/blob/d8d3752af99d7f4c25c0b... This creates a new thread pool for each login request. That's a terrible idea. If anything create it once statically and re-use it. Or just perform your actions in the calling thread as you're just issuing a .get() on the future anyway. Again, it's needless complexity.