Comment 1 for bug 1005540

I'll need some help with this, since I'm actually not too familiar with ElGamal, but I can draw a few parallels to RSA.

PyCrypto appears to have originally been designed to be an assortment of fast, low-level cryptographic primitives that can be composed to implement higher-level protocols. The target audience has really just been other crypto implementers. Unfortunately, due to being the top search result for 'python cryptography', a lot of ordinary application developers have been using it directly without really knowing what they are doing.

Crypto.PublicKey.RSA is an implementation of textbook RSA, and there's no good way to change it without breaking things for other developers who understand this and implemented the appropriate padding on top of it (e.g. the paramiko developers). We've recently added the Crypto.Cipher.PKCS1_OAEP and Crypto.Signature.PKCS1_PSS modules, so that we can at least tell people to use those instead of the raw RSA primitive.

Crypto.PublicKey.ElGamal is similar. It implements textbook ElGamal, by design. This is known, and while it's an unfortunate design decision, it's probably not going to change any time soon. We assume that application developers are implementing standard protocols with an appropriate level of understanding of what's going on, and with some interoperability testing (if they're not doing this already, they're screwed anyway). We should probably implement some sort of standard padding scheme on top of the ElGamal primitive, like we did with RSA. (Is there even a standard padding scheme for ElGamal?)

I'd like to focus the discussion on vulnerabilities, if any, under the assumption that textbook ElGamal is *not* being used. Can any of you comment on that?