Election-Tech-Initiative / Election-Tech-Initiative/electionguard-core2

🐞 Hashed ElGamal use consistent block width

Open
#358 0 comments 0 reactions 0 assignees View on GitHub
bug
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.