,
28 tweets,
9 min read
Read on Twitter
Good Morning Australia! Good Evening Switzerland! Today @VTeagueAus, Olivier Pereira & I are releasing details of a second critical flaw in the Scytl/SwissPost #evoting code base. As well as several other soundness issues in other zero knowledge proofs in the system.
As before () I am going to use this opportunity to provide some context. And, wow, is there a lot of context to unpack.
Starting with the critical issue: we found a flaw in the Decryption Proof in the system that would allow an insider to spoil votes for candidates they didn't like and, as in the case of the previous shuffle proof issue, create a "proof" that said they had done no such thing.
Unlike the previous issue, this attack would leave a trace, but the proofs would say everything is fine. It would be like seeing smoke coming out of your car engine but with no warning light on the dashboard.
Along with our paper documenting the issue, we are also releasing code that demonstrates the issue in the SwissPost code base:
@NSWEC decided to respond to our private disclosure via a public press release a few days ago: elections.nsw.gov.au/About-us/Media… - Considering that they were impacted by the earlier issues, it is an open question as to *why* they are not impacted by this one.
You can also read an analysis about what a second critical flaw in the SwissPost code base means for iVote here: pursuit.unimelb.edu.au/articles/what-…
In my opinion, it is important to understand this issue in context, which is one of the reasons we are also releasing details of a number of other major issues that we found with the zero knowledge proofs in the system.
-These are *not* isolated, easily fixed, issues-
-These are *not* isolated, easily fixed, issues-
The following tweets are a summary of the other issues that we found that we are publicly disclosing today. Some are implementation issues that may impact soundness, some are...well I'll get to them.
The weak Fiat-Shamir transform leading to the Decryption Proof break impacts many of the other ZKP implementations (they all share a common base implementation) - we show how this impacts the soundness of the Schnorr Proof (this likely cannot be exploited in Swiss Post) 
One of the first issues I found in the code was a critical break in the OR Proof construction (which reduces it to not-a-proof at all). Why is there an OR Proof in this code? Great question! Scytl confirmed to me via email that it had never been used in a real system.
echo -n "I'll be concise and to the point, and in good faith I will tell you that I think there is an issue in your OR proof construction (com/scytl/cryptolib/proofs/maurer/factory/ORProofGenerator) - 2019-03-14" | sha256sum
The above commitment was from an email I sent Scytl asking if the OR Proof had ever been used as I was concerned that (like as happened before with the Shuffle Proof) that non-Swiss evoting code had also been released along side the Swiss code.
Anyway, this OR Proof was missing a vital check in the verifier that resulted in it just not functioning at all. As I said before, this was completely dead code. But very broken dead code nevertheless.
Interestingly the presence of the OR Proof seems to violate the swiss evoting ordinance: "The documentation on the system and its operation must explain the relevance of the individual components of the source code for the security of electronic voting". admin.ch/opc/en/classif…
Finally, the underlying proof framework that drives many of the ZKPs uses a non-collision resistant hash function. One of the key assumptions for the soundness of non-interactive ZKPs is that the hash function must act like a random oracle. It does not.
Many of these issues are not exploits in themselves, but are indicators of insufficient skill/attention/auditing in the design, implementation and checking of the system. None of these should have survived a competent audit.
(How many audits has this system gone through again?)
(How many audits has this system gone through again?)
I can confirm that @matthew_d_green was wrong about this one.
I wasn't asking a hypothetical ()
We have found critical issues in 2 major components of this system, and...*counts on fingers*...all of them if you count the many soundness issues in the other ZKP implementations.
And +1 if you count the dead OR Proof.
We have found critical issues in 2 major components of this system, and...*counts on fingers*...all of them if you count the many soundness issues in the other ZKP implementations.
And +1 if you count the dead OR Proof.
For the record, I asked Scytl if they would issue a public apology for their initial press release that stated that the initial criticisms of the their system were "based on misunderstandings related to the cryptographic mechanisms"
They are still considering.
They are still considering.
I think we can all agree that this tweet aged very, very well
It is a good time to remind everyone that the presence of Zero Knowledge Proofs in the swiss system was one of the major selling points. If anything should have been polished, audited, impenetrable it should have been the proof implementations.
They were not.
They were not.
And so here we are. Let me predict the public responses:
"A hacker would have to compromise several systems in order to get a chance at pulling this attack off, and it would be detectable"
"The PIT worked and now the code is battle-hardened, what a success"
"A hacker would have to compromise several systems in order to get a chance at pulling this attack off, and it would be detectable"
"The PIT worked and now the code is battle-hardened, what a success"
None of this matters. The exploitability of this flaw, or the previous flaw don't really matter. What really matters in terms of the analysis of these systems is that this system was supposedly "state-of-the-art" and "ready for the challenge"
It has been found wanting.
It has been found wanting.
If you are Swiss, and this all concerns you I'd suggest looking into your political options, contacting representatives, @eVoteMoratorium (wecollect.ch/de/campaign/ev…) among others.
In my opinion, you should be asking serious questions of the entire development and funding process.
In my opinion, you should be asking serious questions of the entire development and funding process.
If you are Australian, and this all concerns you, after all many of you just participated in an election on software that clearly shares code with the Swiss system. You should be pushing for transparency in your evoting systems:
pursuit.unimelb.edu.au/articles/what-…
pursuit.unimelb.edu.au/articles/what-…
If you are in a country that is also adopting/has adopted evoting. Many of the point in the above linked article apply to you to. Without openness & transparency many of these issues, and possibilities for manipulation, would have gone undetected.
I'm probably going to get some pushback again for "politicizing" this again. But:
1) This is software that determines national power distributions ffs
2) I run a non-profit that fights with & for marginalized communities. Everything is political, deal with it.
1) This is software that determines national power distributions ffs
2) I run a non-profit that fights with & for marginalized communities. Everything is political, deal with it.
