The paper notes another, distinct, attack possibility: > Before going to this, we mention quickly another mistake in the design that could in itself have led t

The paper notes another, distinct, attack possibility: > Before going to this, we mention quickly another mistake in the design that could in itself have led to devastating attacks. The generators that are given in public- key.json are generators of the whole multiplicative group. However, due to the Chinese remainder theorem, it is a good practice to use a generator of prime order. In the present case, the generators will have their order divisible by 2, and therefore there is a huge risk that one bit of information leaks from a ciphertext. In a context like e-voting where a ballot can have a very simple form, this bit of information could reveal a lot of the vote (or even all of it in the case of a yes/no question). In principle, we would have had to investigate more in this direction. But due to the main attack that is much easier and far more powerful, we keep this as a remark. https://arxiv.org/pdf/1908.05127.pdf https://arxiv.org/pdf/1908.05127.pdf This still leaves the question why the developer(s) decided to roll his/her own crypto in this way: > A possible explanation is a confusion with the key size that can be used when using elliptic curves for which the Number Field Sieve algorithm does not apply. This is such an obvious mistake that the entire protocol (whether or not it's ever documented) might be vulnerable. > Another less excusable but still possible explanation might be related to the use of the Ethereum blockchain. In the Solidity programming language that is used to write smart contracts, the bit size of the largest supported integers is 256. Maybe the authors did not want to write a multiprecision arithmetic library that would have been required to deal with larger key sizes. This hypothesis is supported by frequent tests in the source code, checking that the big integers they manipulate are not bigger than SOLIDITY_MAX_INT. This seems more likely. However, that last sentence checking for overflow sounds like another trove of vulnerabilities. Moreover, the claim by the developer in the ZDnet article that a patch is forthcoming seems suspect given that it will need to also include multiprecision arithmetic functionality, where there are still more opportunities for snafu.