[votes]

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. The malicious server will not be directly able to write to the air-gapped server.

[XMPPwocky]

"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, I can't tell what the signature is actually over - but if it's, say, just a candidate name or ID, then... without ever decrypting the "encrypted vote", I can figure out who voted for what by just trying possible values and seeing if I can validate their signature.

[votes]

Thanks for commenting. If you are concerned that our signature is over candidate name or ID, we don't do that. We sign the encrypted vote and not the plain text. We verify it on the air-gapped system.