,
7 tweets,
2 min read
Read on Twitter
Scytl, the company that developed the broken @swisspost voting system, put out a misleading statement about what the problem in their system is. I think it’s worth unpacking. 
The BG mix proof in their system has a “setup” phase in which the parameters for the proof are chosen. That means the parameters need to be chosen by a trusted party or a verifiable process, not chosen during the proving routine (as Scytl currently does.)
From an API perspective, the parameters should be an *input* to the Prove routine. Scytl didn’t realize this. They decided to put the Setup routine inside the Prove routine, which is the cryptographic equivalent of trying to walk through a glass door.
Scytl and @swisspost are trying to write this off as some sort of arcane argument about “how to generate parameters”, when the misunderstanding here is much deeper and more fundamental. It’s like they’ve been using the shaft of the hammer to pound down nails.
They’re also trying to use some kind of “we knew about this serious bug and failed to fix it” defense, which is frankly even worse than the alternative. You knew, and you left a devastating flaw in? And you should be trusted, how?
It is very hard to convey how bad this looks from an expert perspective. It’s like meeting a “surgeon” who doesn’t realize that a scalpel should be sterilized between patients; and when you point this out, they try to explain scalpel-reuse as “standard”.
Also, some folks object to my colorful analogies. So here’s the same statement expressed in technical language: “Scytl used a proof that relies on a Common Reference String and didn’t realize this, so they generated the CRS at Proving time.”
