Election-Tech-Initiative
🐞 Incorrect generation of nonces for encryption of ballot selections
Is there an existing issue for this?
- [X] I have searched the existing issues
Current Behavior
encrypt_selection does this:
selection_description_hash = selection_description.crypto_hash()
nonce_sequence = Nonces(selection_description_hash, nonce_seed)
selection_nonce = nonce_sequence[selection_description.sequence_order]
disjunctive_chaum_pedersen_nonce = next(iter(nonce_sequence))
The nonce_seed value comes from a parameter to the function.
The ElectionGuard spec says: "For each option listed in the election manifest file [where an "option" here refers to a contest selection], the nonce used to encrypt that option is derived from the contest nonce ($R_C$) and the selection label for that option ($L_S) as $R = H(L_S, R_C)$."
So, the code that derives nonce_sequence is fine. But the next two lines are not compliant with the spec, because the whole sequence_order part is (or should be) subsumed in the selection_description_hash.
Instead, the last two lines should read something more like:
selection_nonce, disjunctive_chaum_pedersen_nonce = nonce_sequence[0:1]
This distinction is important for anybody trying to implement the spec correctly. It would be helpful if the spec were more clear on nonce sequences. Right now it's relatively silent on this.
Expected Behavior
No response
Steps To Reproduce
No response
Environment
No response
Anything else?
No response
thank you @danwallach this is an important issue we plan to address in the 2.0 specification when we want to support ballot expansion / rehydration use cases, which we hope to deliver in a very early release
