🐞 Create Sample Data for 1.0.0 Preview

[keithrfung]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Existing Data displayed is currently the 0.95 data not the 1.0 preview data.

https://github.com/microsoft/electionguard/tree/main/data/1.0.0-preview-1/sample/hamilton-general

Expected Behavior

No response

Steps To Reproduce

No response

Environment

- OS:

Anything else?

No response

[ramsdell]

This sample data seems to have problems with hashing. In particular, it appears that hash checks in Spec Steps 2, 3, 4, 5, and 8 fail. What's odd is the hash check in Step 9 succeeds. Here is the output from the MITRE verifier omitting the spoiled verifier checks. I studied my code and I could see no mistakes, but the problem could be with me. Something doesn't add up.

julia> include("src/Run.jl")
"../electionguard/data/1.0.0-preview-1/sample/hamilton-general/election_record"

julia> er=load(path);
Loading jefferson-county-primary.
Found v0.95 election records as expected.

julia> check(er)
jefferson-county-primary
 1. Non-standard parameters were found.
 2. Guardian 1 pubkey is invalid.
 2. Guardian 2 pubkey is invalid.
 2. Guardian 3 pubkey is invalid.
 2. Guardian 4 pubkey is invalid.
 2. Guardian 5 pubkey is invalid.
 3B. Election extended base hash is not valid.
 4. Ballot 03a29d15-667c-4ac8-afd7-549f19b8e4eb has a bad selection encryption.
 5. Ballot 03a29d15-667c-4ac8-afd7-549f19b8e4eb fails to adhere to vote limits.
    The failing contest is justice-supreme-court.
 6. Ballot chaining validity was not checked.
 7. Tally aggregation is correct.
 8. Tally partial decryptions are incorrect,
    30 out of 30 incorrect.
 9. Tally substitute decryptions are correct.
10. Coefficients validated.
10. Missing tally shares are correct.
11. Tally decryptions are correct.
11. Tally selections agree with the manifest.

[cryptosidh]

For hashing, the verifier takes the output of SHA-256, interprets it as an integer and reduces it modulo q-1. This is in line 47 of Hash.jl here: https://github.com/mitre/ElectionGuardVerifier.jl/blob/2f8ac2ab83e5225dbaf8ba90a373c8f08923ba03/src/Hash.jl#L47

But ElectionGuard takes these values modulo q and not modulo q-1. See here in the python code for example:
https://github.com/microsoft/electionguard-python/blob/3a2186f9033e2ffe9f90bff0935d32add9e6a352/src/electionguard/hash.py#L101

This has not been a problem with the previous data because the v0.95 hamilton-general data set uses the standard parameters where q = 2^256-189. This means that the reduction never actually does anything, not modulo q and not modulo q-1, because a SHA-256 output gives an integer in [0, 2^256-1] and the chance for it to be larger than or equal to q are vanishingly small. But the 1.0.0-preview-1 data set uses parameters where q = 2^16-15. So, every SHA-256 output is actually reduced modulo q-1, which is different from the mod q value. This may be the problem.

[ramsdell]

Changing the hash modulus from q-1 to q fixes the problem for the preview sample data. It also makes no difference to the output for the 0.95.0 sample data. The problem is fixed.

I have no idea why I used q-1. I derived my code from the Python code, so I'm not sure what happened. In any event, the draft spec is correct.

[ramsdell]

I see what happened. The modulus in the Python code was changed in commit f913f35e466b6f66c63cbcdc1c4912818b5292dd on February 9th and I missed the change.