hashing doesn't correctly handle some corner cases

Issue

Description In experimenting with my “educational” version of ElectionGuard, where I accumulated the whole formula of every operation on ElementModP and Q, I discovered a few misfeatures in the hash function.

• If the value being hashed is the integer 0, that’s treated by Python as “false” and is hashed as “null”
• There were some cases where lists weren’t being hashed recursively, but were instead being converted to a string and then hashed as a string

None of these impact correctness, since the hash still properly depends on the value in question, but they do impact portability, in the sense that another programming language might properly implement the same hash function with identical behavior.

The patch is pretty simple, only a few changes in hash.py

[rc-ms]

Thanks for this thread and discussion. We hope to address this immediately after our next release. We plan to enable a suite of more efificient unit tests with prescriptive values such as you indicate.

[AddressXception]

Thanks @rc-ms, I’m looking forward to seeing it. Do you have any indication of roughly how far away that is likely to be?

We are pulling this in to the current iteration.