3 ms·

Not necessarily true. Ideally you want things like vote encryption and confirmation code generation to occur in the client, where they can be verified by the vo

Not necessarily true. Ideally you want things like vote encryption and confirmation code generation to occur in the client, where they can be verified by the voters themselves. Otherwise, who is to say the election server itself is not compromised or outright designed to manipulate results. Of course, this is only useful paired with a voting protocol that allows verifying that your own vote was counted, while obscuring its association with any individual voter. See [1]. This is helpful even if only a tiny fraction of voters do verify it, say by running a browser extension that checksums the downloaded Javascript. Because of birthday paradox like results, if votes are verifiable, and a small percentage of voters properly verify their votes, then the chances that the server can modify the election results significantly (e.g. by shipping malicious javascript to some users) without being caught, are actually fairly small. [1] https://www.usenix.org/legacy/events/sec08/tech/full_papers/adida/adida.pdf https://www.usenix.org/legacy/events/sec08/tech/full_papers/... p.s. Of course, an issue with this system is that voters voting on a compromised computer might have their votes hijacked anyways (which is true of any remote voting protocol I know), and that verification codes aid in things like vote selling (some solutions exist, using verification code decoys and the like).

superuser2 12y ago
> who is to say the election server itself is not compromised or outright designed to manipulate results Not Javascript. http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/
- lazaroclapp 12y ago
  Javascript is downloaded by the client and can be verified by the client. I know the server can serve malicious Javascript, but then a client extension can check it. If the server doesn't know which clients are performing verification and which aren't, then it risks being found out. And yes, that article mentions that it's safer to perform the entire protocol in an extension. But the point of the "verifier extension" is that then you don't need every user to use a modified browser[1], just a threshold number of users. It would be even better if browsers provided decent crypto primitives and more compartmentalized runtimes, of course. The point of client side processing here can be seen, if you want as "open sourcing the code that will actually handle my vote" vs "open sourcing some code and promising that it is the code that will handle my vote". Even with the limitations of Javascript security, the former is better than the later, and the later is better than closed source in the server, which is the present situation. Arguably a dedicated (phone?) app would be better and dedicated hardware even better[2]. But then you have to deal with rolling that out to tens or hundreds of millions of people. [1] Chrome extensions are usually also partially compartmentalized Javascript. [2] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html http://googleprojectzero.blogspot.com/2015/03/exploiting-dra...

superuser2 12y ago

> who is to say the election server itself is not compromised or outright designed to manipulate results Not Javascript. http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/

lazaroclapp 12y ago
Javascript is downloaded by the client and can be verified by the client. I know the server can serve malicious Javascript, but then a client extension can check it. If the server doesn't know which clients are performing verification and which aren't, then it risks being found out. And yes, that article mentions that it's safer to perform the entire protocol in an extension. But the point of the "verifier extension" is that then you don't need every user to use a modified browser[1], just a threshold number of users. It would be even better if browsers provided decent crypto primitives and more compartmentalized runtimes, of course. The point of client side processing here can be seen, if you want as "open sourcing the code that will actually handle my vote" vs "open sourcing some code and promising that it is the code that will handle my vote". Even with the limitations of Javascript security, the former is better than the later, and the later is better than closed source in the server, which is the present situation. Arguably a dedicated (phone?) app would be better and dedicated hardware even better[2]. But then you have to deal with rolling that out to tens or hundreds of millions of people. [1] Chrome extensions are usually also partially compartmentalized Javascript. [2] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html http://googleprojectzero.blogspot.com/2015/03/exploiting-dra...