Election-Tech-Initiative / Election-Tech-Initiative/electionguard-core2
🐞 Hashed ElGamal use consistent block width
- Dominant language
- C#
- Stars
- 14
- Forks
- 12
- PR merge metrics
- No merged PRs in 30d
Description
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current Behavior
the hashed elgamal process uses a 32 byte block length but reserves a few bytes for encoding. the indiator is sizeof(uint16_t) in the c/c++ constants.h file but in the current implementation we would need to guarantee the width of the indicator, which is unnecessarily complex.
Instead, we should modify the `HASHED_CIPHERTEXT_PADDED_DATA_SIZE` enumeration to only specify orthogonal boundary values as multiples of the block width and handle the indicator inline with truncation.
For instance, currently `HASHED_CIPHERTEXT_PADDED_DATA_SIZE::BYTES_512` actually equals 510 on most systems but it should instead just equal 512.
Then, we handle the edge cases as follows:
1. if the encryption body is less than the value `adjustedLength = (maxLength - indicatorSize)`, just encrypt it (with or without padding)
2. if the encryption body matches adjustedLength then encrypt it.
3. if the encryption body is greater than adjustedLength and truncation is disabled, throw and exception
4. if the encryption body is greater than adjustedLength and truncation is enabled, truncate and encrypt it.
this is only a slight adjustment to the current behavior.
### Expected Behavior
_No response_
### Steps To Reproduce
_No response_
### Environment
```markdown
- OS:
```
### Anything else?
_No response_
Contributor guide
Assessment
This issue has not been assessed yet.