Various minor issues and potential issues
Brief Description/ Summary
Several issues, and potential issues, in the documentation are highlighted below.
- In several places, the way in which the Fiat-Shamir transform is implemented does not guarantee the properties claimed (without further assumptions). The additional assumptions appear to be satisfied when the proofs are used but given how computational inexpensive the fixes are I highly recommending hardening the transform.
- There are numerous ambiguities in the protocol description due to overloaded notation and undefined parameters.
- There are mistakes in the cryptographic definitions.
- The manner in which parties authenticate to each other is not adequately defined. (As the protocol document itself acknowledges) I, nevertheless, emphasises the issue because the security claims do not hold without very strong authentication.
- In various places it is not clearly explained how the cryptographic protocol and formal model match the requirements in (VEleS - Verordnung über die elektronische Stimmabgabe) and it's technical annex (VEleS Art).
I expect that the release of the code and the detailed pseudocode algorithms will resolve most of the issues described by providing a more detailed description of the protocol. I raise them, in part, to provide a partial reference on key information that is currently missing.
Recommendations
I have two high level recommendations on the protocol and specification. I know the developers are already aware of both issues but they warrant repeating.
Strong Authentication: The specification should clearly articulate how all parties authenticate their communication to each other; the exact details of this are crucial to the security of the protocol. This authentication should be implemented so that no messages can be changed, dropped or added without detection if per group only one of the control components works correctly.
Compartmentalisation: The various cryptographic components and protocol phases should be designed to provide the strongest practical security guarantees under minimal assumptions. Each cryptographic component should guarantee the properties it claims without relying on unstated assumptions. The security properties verified by each phase's audit should be explained.
Impact
The raised issues are with the documentation not the system.
Severity
Medium