Using the `camshoup` verifiable encryption package

[Olshansk]

I recently looked into using the camshoup package to be used in a VRFworkflow, but have a few questions:

1. Is it possible to rename DecryptionKey and EncryptionKey to VerificationKey and SecretKey respectively?

2. Image 1 below shows that the EncryptionKey can be retrieved from the DecryptionKey. I looked through some of the reference papers (image 3) and additional documentation (image 2), but still don't fully understand how this should be used.

   If a verifier, who has access to the DecryptionKey, can retrieve the EncryptionKey, then anyone can recreate the proof. My expectation is that the DecryptionKey (i.e. the Public Key) can be used for verification, the EncryptionKey (i.e. the Secret Key) can be used for encryption, and DecryptionKey can be derived from the EncryptionKey.

   If my understanding here is incorrect, then the first question is a moot point.

3. What is the purpose of the numMsgs parameter when calling NewKeys? It seems that it controls the number of messages that the ciphertext could contain but is this a design decision or a technical limitation? In other words, why not simply use the same key and treat each ciphertext as a separate message (i.e. numMessages is always exactly 1).

Image 1: README in this github repo:

Image 2: README in this github repo:

Image 3: The referenced paper Practical Verifiable Encryption and Decryption of Discrete Logarithms:

[mikelodder7]

I recently looked into using the camshoup package to be used in a VRFworkflow, but have a few questions:

1. Is it possible to rename DecryptionKey and EncryptionKey to VerificationKey and SecretKey respectively? No these are really encryption and decryption keys, not just proving and verifying.

2. Image 1 below shows that the EncryptionKey can be retrieved from the DecryptionKey. I looked through some of the reference papers (image 3) and additional documentation (image 2), but still don't fully understand how this should be used. If a verifier, who has access to the DecryptionKey, can retrieve the EncryptionKey, then anyone can recreate the proof. My expectation is that the DecryptionKey (i.e. the Public Key) can be used for verification, the EncryptionKey (i.e. the Secret Key) can be used for encryption, and DecryptionKey can be derived from the EncryptionKey.

The verifier shouldn't have access to the decryption key. The prover is showing they encrypted a message(s) to the encryption key. The verifier can check that the statement is true.

If my understanding here is incorrect, then the first question is a moot point.

3. What is the purpose of the numMsgs parameter when calling NewKeys? It seems that it controls the number of messages that the ciphertext could contain but is this a design decision or a technical limitation? In other words, why not simply use the same key and treat each ciphertext as a separate message (i.e. numMessages is always exactly 1).

This stems from the paper that you can have multiple messages in a single proof vs creating N proofs. Efficiency and succinctness are two reasons for this approach. It's not a technical limitation.

[mikelodder7]

Addressed

[Olshansk]

@mikelodder7 Per the naming convention, that you can retrieve the EncryptionKey given the DecryptionKey in the function I highlighted above?

Doesn't this give the verifier the ability to encrypt as well?

[mikelodder7]

The verifier can only decrypt if they have the decryption key which is not needed to verify proofs

[massitaverna]

I see an inconsistency - in terms of the goal of the proof - between the above message:

... The prover is showing they encrypted a message(s) to the encryption key.

and the paper which claims to prove that:

The message encrypted ... is the discrete logarithm of an element.

In more details, calling m the message which gets encrypted, according to the paper the property that they want to be verifiable is "m is the discrete log of a public known value y in a given base g", while the message above, as well as the camshoup's README in this repo, states that the verifiable property is "m has been encrypted with a given public key".

Am I missing something? Or the declared goal of the camshoup implementation is somewhat misleading?

[Olshansk]

@massitaverna I'm slightly confused as well.