You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, a verifier does not need to recompute the crypto_hash of Manifest, ContestDescription, or SelectionDescription. Those are not currently included in the election record, except indirectly in the SubmittedBallot objects.
It may be useful for a verifier to have the ability to recompute the crypto_hash, as a check against possible manipulation, and check those against what is explicitly included in the election record Manifest.
Currently a verifier not using the reference library has to reverse engineer the hash function in the reference library.
Im not sure if something better can be done about that, or if hash.py is a good enough "spec".
Similarly, there is some wiggle room about which fields are included in the hash, and their order. Again, we could just let the reference library be the spec or we could document it more formally. In either case, the reference library could only make changes to the crypto_hash on a major (breaking) version change.
Anything else?
No response
The text was updated successfully, but these errors were encountered:
Is there an existing issue for this?
Suggestion
Currently, a verifier does not need to recompute the crypto_hash of Manifest, ContestDescription, or SelectionDescription. Those are not currently included in the election record, except indirectly in the SubmittedBallot objects.
It may be useful for a verifier to have the ability to recompute the crypto_hash, as a check against possible manipulation, and check those against what is explicitly included in the election record Manifest.
See Issue #243 for motivation.
Possible Implementation
Currently a verifier not using the reference library has to reverse engineer the hash function in the reference library.
Im not sure if something better can be done about that, or if hash.py is a good enough "spec".
Similarly, there is some wiggle room about which fields are included in the hash, and their order. Again, we could just let the reference library be the spec or we could document it more formally. In either case, the reference library could only make changes to the crypto_hash on a major (breaking) version change.
Anything else?
No response
The text was updated successfully, but these errors were encountered: