Is there an existing issue for this?
Suggestion
When encrypting a ballot, it may be desierable to precompute selection encryptions and then combine the selection encryptions to formulate a ciphertext ballot contest. The purpose is to precompute as much data as possible to improvethe perception of a performance improvement when encrypting a ballot.
At a high level, the Encryption Mediator maintains a buffer of precomputed elgamal ciphertext encryptions of zero and one (along with its proofs). This may actually be implemented as two separate buffers. When a ballot is encrypted, rather than elgamal encrypting the selection at the time of the function call, instead a suitable value is chosen from the appropriate buffer.
The use of the selection buffer should be optional and therefore will require completely separate high level stateful logic functions in order to execute this process. Additionally, since we are precomuting selections using a generic nonce, it will break the deterministic nature of nonce derivation in the current synchronous method. This consideration is important because it may have knock on effects for things like the compact ballot.
In order to implement this change, the interior of the encryptSelection function will need to be modified (or a parallel version created) to support fetching values from a queue. the queue may also be passed into the function call as a parameter in order. The queue is a stateful object dependent on the runtime context of the application (the public key). the existing workflow for encrypting at the time of function call must also be maintained as this new workflow is considered an exceptional case and it is preferable to use the existing workflow.
Some implementation considerations:
- in Async.hpp there is already an AsyncQueue and other primitives (e.g. CallableWrapper) that can be reused for the buffer queues
- the current encryptContest function call uses a threadpool for calling encryptSelection and that functionality should be maintained in order to take advantage of the hardware
- the loop to refill the buffer must not interfere with calls to encrypt using the buffer. the simplest implementation is likely to have a function call to refill the buffer manually.
- because all of this is stateful, it is likely appropriate to put the state in the Encryption Mediator
Possible Implementation
class ElGamalEncryptionBuffer {
....
};
class EG_API EncryptionMediator {
std::unique_ptr<CiphertextBallot> encryptFromBuffer(const PlaintextBallot &ballot,
bool shouldVerifyProofs = true) const {
return encrypt(ballot, *_buffer, shouldVerifyProofs);
}
private:
std::unique_ptr<ElGamalEncryptionBuffer> _buffer;
};
std::unique_ptr<CiphertextBallot> encrypt(const PlaintextBallot &ballot,
ElGamalEncryptionBuffer &buffer,
bool shouldVerifyProofs = true) const {
# implement
}Anything else?
No response
Is there an existing issue for this?
Suggestion
When encrypting a ballot, it may be desierable to precompute selection encryptions and then combine the selection encryptions to formulate a ciphertext ballot contest. The purpose is to precompute as much data as possible to improvethe perception of a performance improvement when encrypting a ballot.
At a high level, the Encryption Mediator maintains a buffer of precomputed elgamal ciphertext encryptions of zero and one (along with its proofs). This may actually be implemented as two separate buffers. When a ballot is encrypted, rather than elgamal encrypting the selection at the time of the function call, instead a suitable value is chosen from the appropriate buffer.
The use of the selection buffer should be optional and therefore will require completely separate high level stateful logic functions in order to execute this process. Additionally, since we are precomuting selections using a generic nonce, it will break the deterministic nature of nonce derivation in the current synchronous method. This consideration is important because it may have knock on effects for things like the compact ballot.
In order to implement this change, the interior of the encryptSelection function will need to be modified (or a parallel version created) to support fetching values from a queue. the queue may also be passed into the function call as a parameter in order. The queue is a stateful object dependent on the runtime context of the application (the public key). the existing workflow for encrypting at the time of function call must also be maintained as this new workflow is considered an exceptional case and it is preferable to use the existing workflow.
Some implementation considerations:
Possible Implementation
Anything else?
No response