Possible error in SchnorrProof.make_schnorr_proof(), or spec 2.A changed?

[JohnLCaron]

In writing a validator for equation 2.A ("2. Guardian Public-Key Validation")

   (A) The challenge c i,j is correctly computed as c = H(Q, K, h ) mod q, where Q is the crypto_base_hash.

This test is failing in my validator. But if I remove Q, it works.

c = H(K, h ) mod q.

Looking at line 80 of schnorr.py:

c = hash_elems(k, h)

possible error? Or spec had to be changed because crypto_base_hash not available?

[JohnLCaron]

So the question is for @benaloh or another crypto expert, as to whether the challenge should / must include Q in it, and to the python implementors if the omission was deliberate, and if so why. If its inadvertent, I can submit a PR.

[benaloh]

Yes. The base hash Q should be included in all of the subsequent hash computations used for challenges and otherwise. This binds all of the parameters together so that an attacker can't try to mix and match things in inappropriate ways.

[JohnLCaron]

Fixing this proof will mean that validation will break for previously generated election records.

Perhaps the record serialization needs to be versioned, since its likely other breaking changes will be needed in the future? Perhaps add a version field to CiphertextElectionContext?

[kiniry]

It looks like this computation was correctly implemented in the original C implementation and the Rust verifier. How did this change happen/evolve in the Python and new verifier(s)? That's a large change in protocol.

[danwallach]

Probably happened because I typed it in wrong from the spec.

[AddressXception]

IIRC, this was a decision made to allow guardians to exist (and be verifiable) externally to a specific election context. Is this a feature we want to keep, or do we want to instead follow the specification and require that new guardians are seeded for every election?

Some use cases have allowed for the same guardians to be used across multiple elections without having to run a key ceremony. I can see value in keeping this, but I can also see a strong case for the protocol forcing the regeneration of guardians for every election and thus requiring the application layer to handle the user experience as it sees fit.

We already bind a specific set of guardians to a specific ElectionDescription via the CiphertextElectionContext.elgamal_public_key and the crypto_extended_base_hash, but the reverse is not true. Is that enough?

Should we update the code, or should we update the spec?

[benaloh]

I'd argue against forcing new keys for each election. This seems to be more of a policy decision outside of EG.

If the guardian set changes, there should definitely be new keys. One can argue that for large, distinct elections, new keys are a good idea even if the same guardians are used. But there are also use cases where the same guardians are to be used for a sequence of separate elections that may occur in rapid-fire succession, and there is no reason to mandate burdensome re-keying for such cases.

[AddressXception]

I'd argue against forcing new keys for each election. This seems to be more of a policy decision outside of EG.

If the guardian set changes, there should definitely be new keys. One can argue that for large, distinct elections, new keys are a good idea even if the same guardians are used. But there are also use cases where the same guardians are to be used for a sequence of separate elections that may occur in rapid-fire succession, and there is no reason to mandate burdensome re-keying for such cases.

Ok sounds good, I'm reading that then as we should modify the spec to match the python repo instead of modifying the python repo to match the spec. Have we reached a quorum?

[benaloh]

The (extended) base hash should be included in (almost?) all subsequent hash computations in an election. This is what binds events to a particular election.

Can the commitments to key shares be an exception? Probably ... since this is mostly an internal negotiation between guardians.

Should the commitments to key shares be an exception? Probably not ... as the cost of the extra binding is minimal and the public may have some interest in resolution of disputes between guardians.

[AddressXception]

The (extended) base hash should be included in (almost?) all subsequent hash computations in an election. This is what binds events to a particular election.

Can the commitments to key shares be an exception? Probably ... since this is mostly an internal negotiation between guardians.

Should the commitments to key shares be an exception? Probably not ... as the cost of the extra binding is minimal and the public may have some interest in resolution of disputes between guardians.

ah, just saw this, see my comment on this other issue

[AddressXception]

cross posting from #279

ok great, so for clarity, we'll make the change in #279 to include the commitments as part of the calculation of the crypto_extended_base_hash. #278 will be closed as WONT_FIX and instead the specification will be adjusted so that schnorr proofs do not include the crypto_base_hash in their calculation and guardians are not explicitly coupled to an election (but an election is still explicitly coupled to a set of guardians.