HashedElGamal: Compatibility with the reference implementation

[shreyasminocha]

Manually transferred.

Dependent issue: Election-Tech-Initiative/electionguard-python#646

Depending on what they do or don't fix, we might need to:

• Ensure that we're always serializing integers to 32-bits
• Remove the 0x00 from the KDF computation
• Encode HMAC keys in hex bytes (hopefully not!)

We should also double-check that they are correctly handling inputs that aren't multiples of 32 bytes long.

[danwallach]

Short term: we're not using HashedElGamal and not supporting features that require it (encoding overvotes & write-ins).

In the fall, when ElectionGuard gets past the 1.0x versions in to 2.0, we'll bring this back.

[shreyasminocha]

So in the meantime what should we do about the numBytes field? It causes issues with my compatibility tests, particularly in terms of deserializing and re-serializing the sample data. electionguard-python's padding approach has issues like you described earlier. I saw that electionguard-cpp just errors on plaintexts and ciphertexts whose length isn't a multiple of the block size. Should I implement something of that sort and adjust the tests accordingly?

[danwallach]

Hmm. It really bugs me when we have a "correct" implementation and we have to introduce bugs.

I suggest we introduce a HashedElGamalCompat structure of some kind, which is just an empty shell of a data structure. We can serialize and deserialize, but it has no actual code attached. Since we're not actually using it, we don't care about it yet.