Is there a plan to add an encryption algorithm, for instance, ElGamal?
zhenfeizhang opened this issue · comments
My use case can use a verifiable encryption scheme :-)
Warning: Most of the curves in arkworks are pairing-friendly curves, on which DDH assumptions do not hold, and therefore ElGamal could not be securely implemented.
And this might suggest two ways:
- Add some non-pairing-friendly curves? For example, Curve25519!
- Use linear encryption, which is based on the DLIN assumption. There are several variants, one with IND-CPA, one with IND-CCA.
I thought we can do ElGamal over JubJub, right?
Oh yes. Good points!
ECIES does not require Decisional DH.
Separately, there's little or no reason to use ElGamal over ECIES for any curve. Zcash uses a variation of ECIES over Jubjub. However, be sure to read about potential interoperability pitfalls here: https://zips.z.cash/protocol/protocol.pdf#inbandrationale
ECIES permits many options, which were not specified. There are at least –counting conservatively– 576 possible combinations of options and algorithms over the four standards (ANSI X9.63, IEEE Std 1363a-2004, ISO/IEC 18033-2, and SEC 1) that define ECIES variants [MAEÁ2010].
(Using ElGamal wouldn't solve this problem; there are many ways to do ElGamal as well.)
Yes. Let me correct that actually if one assumes XDH assumption to hold, you can also do ElGamal over pairing-friendly curves.
ECIES does not require Decisional DH.
Separately, there's little or no reason to use ElGamal over ECIES for any curve. Zcash uses a variation of ECIES over Jubjub. However, be sure to read about potential interoperability pitfalls here: https://zips.z.cash/protocol/protocol.pdf#inbandrationale
ECIES permits many options, which were not specified. There are at least –counting conservatively– 576 possible combinations of options and algorithms over the four standards (ANSI X9.63, IEEE Std 1363a-2004, ISO/IEC 18033-2, and SEC 1) that define ECIES variants [MAEÁ2010].
(Using ElGamal wouldn't solve this problem; there are many ways to do ElGamal as well.)
I am wondering if the performance would be one?
To prove a verifiable encryption, it is much easier for ElGamal, i.e., the proof includes a couple of proof of exponents statement over JubJub; compared to ECIES, where you actually need to prove a KDF statement.
(I don't believe Zcash requires a verifiable encryption, so it totally makes sense to use ECIES over ElGamal for Zcash.)
In terms of circuit size, it wouldn't be very costly to use a KDF and authenticated encryption based on Poseidon, say. But it would require some cryptographic engineering work and analysis.
Agreed!
Very good points. With things like Poseidon, the cost is much smaller.
One question: what is your consideration of authenticated encryption? Use a CBC-MAC like in EAX mode? GCM? Or find one suitable for ZKP & Poseidon? (https://eprint.iacr.org/2015/624.pdf)
A polynomial MAC –like Poly1305, but over the native field of the SNARK– can be extremely efficient. You still need to encrypt the tag and/or use a KDF to produce a one-time key.
In #44, I suggest a simple gadget for proving correct ElGamal encryption, which can be used over JubJub.
@zhenfeizhang you can take a look at the basic ElGamal gadget added in #44.