Closed eleanor-em closed 3 years ago
The Guardian
in the future will never be serialized directly. The Guardian
class is designed to be a stateful helper for individuals to use functions but the artifact that needs to be serialized contains significantly less data. We are currently calling this a GuardianRecord
So @keithrfung are you saying that GuardianRecord is a different way of serialising the same data, i.e. the guardian's private key, commitment openings, etc?
The guardian information is serialized to be included in the published Election Record for end to end verification process.
This record ensures that all the required information for the guardian is serialized. The public key and the commitments are included, yes.
Bug Report
This issue was found using ElectionGuard 1.1.15 as published to PyPI.
Expected Behavior After creating a
Guardian
and running the key ceremony with other guardians, it should be possible (sinceGuardian
inherits fromSerializable
) to serialize the guardian usingand then to deserialize the same guardian later with
For example, this would be useful in the asynchronous case where key generation is done well in advance of the key being used to decrypt anything.
Actual Behavior This currently does not work due to a number of inconsistencies between what
write_json
writes, and whatread_json
expects. I have enumerated some of the inconsistencies below:read_json
expects a top-levelid
key, butwrite_json
names the keyobject_id
instead.read_json
expects top-levelnumber_of_guardians
andquorum
keys, butwrite_json
instead creates a nested object:DataStore
does not work (see #316), so deserialising the following elements ofGuardian
also fails:_backups_to_share
_guardian_auxiliary_public_keys
_guardian_election_public_keys
_guardian_election_partial_key_backups
_guardian_election_partial_key_verifications