there is an attack that makes changing a vote v to v' possible by knowing v/v'

[DrShymaa2022]

I'm trying to write an SoK paper about e-voting, and it seems Estonia deserves one alone.

1-Have you read this paper that I think proves the system needs to be fixed https://www.researchgate.net/publication/376231158_On_the_Auditability_of_the_Estonian_IVXV_System_And_an_Attack_on_Individual_Verifiability You should read the 3 attacks, but I think the 3rd is the most severe since it is trivial to get the ratio (v/v') whether through the code described in [https://media.ccc.de/v/37c3-12298-should_e-voting_experience_of_estonia_be_copied#t=965] in fact the vote codes are shown in min 11 -When he talks about end-to-end verifiability, I think your system does not provide it; the verification application verifies "casted as intended", the key application checks "counted as recorded" but there is no check for "recorded as casted". I believe this could happen through a malicious voting application, a malicious device, or maybe a malicious chain like the paper about the French voting system ( the FLEP fixed their system after the paper)

2-He (in the link above) mentions also a secondary server; are you aware of links for more details about this secondary server? I mean to find out where it stands in those attacks and whether it could be used in a fix

3-Does the myID service replies with some info on the signed data or just Meta data? because I have 2 conflicting answers on that: -"The myID service does not retain the signed documents (in fact, you only see the OCSP log)" by the author of https://www.researchgate.net/publication/373483642_Creating_a_Decryption_Proof_Verifier_for_the_Estonian_Internet_Voting_System

-From https://gafgaf.infoaed.ee/en/posts/perils-of-electronic-voting/

"There is a service called MyID, which is a side product of our digital identity infrastructure. We have had it for ages and MyID is the new one currently in beta. Each electronic vote is signed digitally and for giving a digital signature the software has to check if the certificate used for signing is a valid one. The service logs all the attempts to digitally sign a document and provides logs with timestamps, IP addresses, type of identification token and other data. If the log doesn’t contain a certificate check for another digital signature with the same properties as the previous one, but later timestamp, this is the proof needed to make a deal. You can also download full logs in convenient JSON format to be analysed and processed or even order it sent directly to perpetrators e-mail"

So, which is more accurate? thanks

(I did not put any smiles or emojis in this issue, and if it appears then I'm sorry for the annoying irresponsible hacker who could defeat original MCfee antivirus)

[boamaod]

The protocol is described on electoral authority web site, however English version doesn't describe the protocol for OCSP/RFC3161 timestamps, which you can find in Estonian section as part of protocol description 6.1.1-6.1.5. The MyID does not indeed retain anything, because it's just a simple timestamp log (timestamp here meaning just an instance of datetime type data), but certification centre signs the actual OCSP responses and RFC3161 timestamps also returning requests signed by the collection service containing a hash of vote ciphertext. So whatever is the goal, you can work with that data and prove various things depending on the goal and the trust assumptions.

[DrShymaa2022]

So without getting on the details of how now, it is really feasible almost trivial for an adversary to get the ratios (v/v') for all candidate choices v and a desired vote v' -If the above statement is correct, we have the following:

-The 3rd attack in the first paper of the issue can happen like this 1-find an s for every voter with public key y such that y^s = v'/v (v is how the voter voted, v' is the adversary's choice) 2-send to the verification application (c1,c2)= (g^r, v(y^r)) (like the voter voted) 3- send to the Vote Collector as if the generated random number is r'= r+s and the vote is v' i.e., (c1,c2)= (g^(r+s), v' y^(r+s))

v'y^(r+s)= v'(y^r)(y^s) = v'(y^r)(v/v')= (y^r)v ===> the same value of c2 in both cases

The reply here https://twitter.com/trtram/status/1751231814880882753 pointed out to me that there is a check that c1=(g^r) https://github.com/valimised/ivotingverification/blob/published/app/src/main/java/ee/vvk/ivotingverification/util/ElGamalPub.java#L77-L83 Well, if c1 is taken from the vote collector problem solved and the attack will be detected ( different c1 sent to each application), but if c1 (line 80 in the code) comes from the voting application then the problem still persists and could have been done

-According to the paper https://www.researchgate.net/publication/372570425_Individual_Verifiability_and_Revoting_in_the_Estonian_Internet_Voting_System/comments a malicious voting application can fake a malfunctioning then a restart to send to the verification application the data of the voter second attempt while using the first attempt random to create a fake vote as the final one ( I think this can only be detected by double checking through other available services)

-I also suggest you can do some sample audits without any governmental effort and see if there's a counter example of contradiction or not (ask volunteers, possibly from your supporters, to compare the results from MYID service to their QR code, to what they know they've done, or to what is the voting server if possible) There is more on different audits on the twitter thread Ps. Make sure to include in the sample some who did not vote through the internet at all and check that no one voted in their place