Election-Tech-Initiative / Election-Tech-Initiative/electionguard-python
🐞 Incorrect generation of nonces for encryption of ballot selections
- Vorherrschende Sprache
- Python
- Sterne
- 168
- Forks
- 103
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beschreibung
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current Behavior
`encrypt_selection` does this:
```python
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:
```python
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_
Beitragsleitfaden
Bewertung
Dieses Issue wurde noch nicht bewertet.