Talk:ElGamal encryption

The article looks broken, can anybody clean it up? --MrNightLifeLover (talk) 16:30, 21 November 2008 (UTC) We should point out that without padding Elgamal is malleable. --Imran

Should be named??

The title of this article is misleading and should be changed. This is an algorithm, a primitive used to build crypto systems. It is not itself a crypto system. Perhaps a pointer from this title to this article under the better title of 'ElGamal encryption algorithm'. See the cross reference (currently a dangling link) at article cryptography. user ww

I agree. ElGamal is not a complete cryptosystem. Taw 19:58, 6 Apr 2004 (UTC)

Any suggestions for a better name? — Matt 02:36, 3 Aug 2004 (UTC)

It depends on how you define "cryptosystem." To theorists, a cryptosystem is rigorously defined to be a key generator, encryption algorithm, and decryption algorithm. ElGamal fits the bill... On the other hand, I dislike the phrase "discrete log" in the title. Security of ElGamal surely relies on the discrete log assumption, but in fact it needs something stronger (the Decisional Diffie-Hellman assumption, to be precise). --Chris Peikert 22:10, 18 Nov 2004 (UTC)

Chris, while you're right about cryptosystem in a strict sense, the term is used far more by applied crypto people than theory people, so IMHO wikipedia should use that definition. Arvindn 22:45, 19 Nov 2004 (UTC)

How about ElGamal cryptosystem then (also applying the principle that shorter names are better)? — Matt 23:31, 19 Nov 2004 (UTC)

I am OK with either ElGamal cryptosystem or ElGamal encryption or ElGamal encryption algorithm. I think Arvindn's right that cryptosystem, at least on wikipedia, should be reserved to mean a "full package". --Chris Peikert 06:33, 22 Nov 2004 (UTC)

OK, I've plumped for ElGamal encryption and added redirects for the others. — Matt 07:02, 22 Nov 2004 (UTC)

In my opinion the name should be Elgamal cryptosystem. That is the name I used for the german version of the article (Elgamal-Kryptosystem) from which this text is translated. Encryption is misleading, because the text both explains the encryption and decription (I hope this is correct english :-). A cryptosystem perhaps includes encryption and decription. As far as I know the name is spelled "Elgamal" and not "ElGamal".Stern 23:21, 30 Jan 2005 (UTC)

Which algorithm is described here, anyway????

It would seem to me that the algo that is described is the DH encryption, not the ElGamal signature scheme on which DSA is based. user mmy

ElGamal Encryption is based on Diffie-Hellman. ElGamal signatures are a completely different algorithm, and they're indeed similar to DSA and Schnorr signatures. — Preceding unsigned comment added by 2A02:908:1A0:FCA0:1973:6D78:5F52:4AB9 (talk) 13:21, 23 March 2016 (UTC)

error in el-gamal decryption scheme

hello there, the very simple explanation for decrytpting the message m:=(c1,c2) with c2/(c1^x) is apparently not correct.

here is a little example:

Bob:

p:= 11; phi(11) = 10; 10=2*5;

g:=2 (2^5 mod 11 !=1 and 2^2 mod p !=1 and therefore order(2,11)=10)

x:= 5 (0<=x<p-1)

y:= g^x = 2^5 mod 11 = 10;

now PK(p,g,y) = (11,2,10) and SK(11,2,5) = (p,g,x)

Alice:

encrypts m:=7 with randomly chosen k:=9

c:=(g^k,m*y^k) = (2^9 mod 11, 7*10^9 mod 11) = (c1,c2) = (6,4)

and sends (c1,c2)

Bob:

tries to decrypt with in your opinion:

m:= c2/c1^x = 4/6^5 mod 11 = 4/10 != 7

while the original intention was:

m:=(c1^x)^-1 * c2 = (c1^-1)^x * c2 = c1^-x * c2

where ^-1 refers to the inverse of c1 in Z11

therefore:

m:= ([6]^-1)^5 * [4] = ([2]^5 *[4]) = 32 mod 11 * 4 mod 11 = 7

note: 2*6 mod 11 = 1 and then again 2 is the inverse of 6

we hope that helps

How did you calculate this? m:= c2/c1^x = 4/6^5 mod 11 = 4/10 != 7

Note: under division / we DO understand modular inverse: 4/10=4/(-1)=4*(-1)=-4=7 — Preceding unsigned comment added by 157.193.2.198 (talk) 23:15, 15 June 2011 (UTC)

Many fixes needed in this article

The description of ElGamal is incomplete and has some errors.

First, there isn't any discussion of how the parameters p,g are generated. In fact, p should be chosen to be prime, such that p-1 has a large prime factor q (p=2q+1, where q is also prime, is a typical choice). Then g should be chosen to have order q in Z_p. That is, g is not a generator of all of Z_p, but is a generator of a prime-order subgroup of Z_p. If setup is not done this way, ElGamal can be insecure (at least, according to the definition of semantic security).

(The incomplete description of the parameters may be the reason for the bug described above; I haven't looked at it closely.)

Key setup (the choice of x) is merged into the encryption algorithm when it shouldn't be. Also, it should be said that x is chosen at random from Z_q^*.

Bob's message should not be encoded as an arbitrary element of Z_p, but as an element from the subgroup generated by g. Otherwise the scheme may be insecure.

Bob's choice of k should be random from Z_q^*.

It is claimed that breaking the security of ElGamal is as hard as finding discrete logs. This is not known to be true, nor believed to be true. In fact, breaking the semantic security of ElGamal is equivalent to breaking the Decisional Diffie-Hellman (DDH) assumption in the subgroup pf Z_p generated by g.

--Chris Peikert 22:29, 18 Nov 2004 (UTC)

I have translated the German version of the article, but given the accuracy concerns, this should be merged in by someone with a little more knowledge -- for now, it is just there at the end of the article. Mpolo 16:35, Nov 21, 2004 (UTC)

Thanks -- unfortunately, it appears that the German version has many of the same errors that I describe above. One of these days when I have time I will attempt to fix this article... --Chris Peikert 21:34, 21 Nov 2004 (UTC)

That'd be much appreciated, if you have the time. — Matt 21:40, 21 Nov 2004 (UTC)

Fixed this article

Hi all, I rewrote this article with accuracy and security in mind, and I think it is alright now (two of the edits I accidentally submitted as anonymous, rather than via my account). I included discussions of malleability (as suggested above) and efficiency (from the German translation).

However, I haven't done my homework vis-a-vis links to other wiki pages. It would be great if someone could go through the text and take advantage of good linking opportunities.

--Chris Peikert 06:29, 22 Nov 2004 (UTC)

Thanks, it's great work. I've gone through and added a few wikilinks. — Matt 07:02, 22 Nov 2004 (UTC)

A few questions

I think r should be equal to g^k (mod p).

Why do you say hcf (highest common factor) ? Most people talk of GCD or Greatest common divisor. You should link to Extended Euclidean algorithm. -- Nroets 8 July 2005 11:26 (UTC)

ElGamal signatures vs. ElGamal encryption

It didn't make sense to have ElGamal signatures and ElGamal encryption on the same page. There are not many similarities between the two schemes other than both are by Taher ElGamal and are based on discrete logarithm. But there are many differences between the schemes, especially when one looks at the the parameter choices. For example choosing g=2 is ok for the encryption scheme but an insecure choise for the signature scheme. A group for which the Decision Diffie Hellman problem is solvable is a problem for the encryption scheme but not a problem for the signature scheme.

Yep, sounds like the right thing to do. — Matt Crypto 21:36, 22 July 2005 (UTC)

Spelling

The name is spelled Elgamal, not ElGamal. Stern 19:00, 31 July 2005 (UTC)

See Talk:Taher Elgamal for further discussion. I agree with Matt on this one. It's referred to virtually everywhere as "ElGamal". alerante ✆ 00:14, 19 October 2005 (UTC)

Wikipedia goes with most common usage (see Wikipedia:Use common names). All major textbooks I've seen spells this ElGamal, so that is what this article should be named. I agree with User:Matt Crypto and User:Alerante. —Lowellian (reply) 03:20, 20 October 2005 (UTC)

Encryption questions

I'm trying to relate the generalized description in the article to with specific implementations of encryption (like in GnuPG and Applied Cryptography), and I'm wondering about the following:

The article says, Bob chooses a random $y$ from $\{0,\ldots ,q-1\}$, then calculates.... The implementations I've seen ensure that $y$ and $p-1$ are relatively prime. Is this somehow implicit in the article's description?

Also, there is a warning that care must be taken to properly encode the message $m$ as an element of $G$, and not, say, as just an arbitrary element of $Z_{p}$. How exactly can one do that? (I'm asking about using subgroups of $Z_{p}$, not elliptic curves.) Wmahan. 07:12, 26 May 2006 (UTC)

To your first question: When using a group $G$ whose order is a prime q (as recommended in the article) then one should choose y randomly in the interval 0..q-1. Then g^y will be a random element in $G$. The restriction that y is chosen relatively prime in GnuPG is a leftover from sharing code between ElGamal signatures and ElGamal encryption. These two schemes are actually quite different when one considers security requirements. For ElGamal signatures to work one must choose y (rsp. the identifier k is used there) relatively prime to the group order. No such requirement is necessary for ElGamal encryption. Thus sharing code is a risky idea and lead for example to a very severe attack against GnuPG discovered by Phong Nguyen.

To your second question: You can for example choose p=2q+1 where both p and q are prime. Then choose G as the multiplicative subgroup of $Z_{p}$ of order q i.e. the quadratic residues. Now messages m in the range 1..q can be mapped into G by mapping m to $m\left({m \over p}\right)$ where $\left({m \over p}\right)$ is a Legendre symbol. Also note that the resulting cryptosystme is only semantically secure, but not secure against chosen ciphertext attacks. Thus more considerations on the padding would be necessary for a real life implementation. 62.167.39.178 19:53, 28 May 2006 (UTC)

Thank you very much. The second edition of Schneier's Applied Cryptography (1996) says to do the relatively prime thing for encryption too, not just for signing. But I checked the reference linked at the bottom of the article and it says you're right, of course. I suppose GnuPG's extra constraint on y doesn't weaken the algorithm, even if it isn't necessary. Thanks again for the informative answers. Wmahan. 19:01, 31 May 2006 (UTC)

perhaps the above could be added to the article. Since its not always easy to test if a elemet in $Z_{p}^{*}$ is in the subgroup generated by g. --The preceding unsigned comment was added by 131.130.79.169 (talk) 11:23, 19 December 2006 (UTC).

big problems

the mods are left off the equations. how is anyone going to know how to use this? --The preceding unsigned comment was added by 155.91.28.232 (talk) 23:42, 14 March 2007 (UTC).

No. There are not mod operations missing. The article is written in a general form using a group G written multiplicatively. If G is the multiplicative subgroup $F_{p}^{*}$ then all operations are done modulo $p$. However, G can be some other group, e.g. the group of points on an elliptic curve. 85.2.121.89 12:20, 24 March 2007 (UTC)

insecurity of G := F_p^*

I have tagged this statement as "citation needed". The currently referenced "Handbook of Applied Cryptography" specifically states that ElGamal with G=F_p^* is believed to be secure. If this information is out of date, a reference should be supplied to show that.

Also note that some current implementations do use F_p^*, so this is quite important to get right! Mbays 18:49, 22 March 2007 (UTC)

Good point. The statement is at least ambigous, because the term "insecure" itself is unclear without stating an adversarial model. First, the DDH assumption in $F_{p}^{*}$ does indeed not hold, because for a generator $g$ it is possible to distinguish tuples $g^{a},g^{b},g^{ab}$ from $g^{a},g^{b},g^{c}$ with a nonnegligible probability, by computing Legendre symbols of the values. Similarly, from an encryption $(g^{r},y^{r}m)$ we can derive the Legendre symbol of $m$ as follows. Computing the Legendre symbol $(g^{r}|p)$ tells us if $r$ is odd or even. The Legendre symbol $(y|p)=(g^{x}|p)$ tells us whether $x$ is odd or even. Thus we know the parity of $xr$ and thus also the value of $(y^{r}|p)$. Hence, we know the Legendre symbol $(m|p)=(y^{r}m|p)/(y^{r}|p)$. Hence ElGamal encryption over $F_{p}^{*}$ is not semantically secure. Note that if RSA has a same problem when used without padding. Given $c=m^{e}{\bmod {n}}$ one can easily derive the Jacobi symbol $(m|n)=(c|n)$. Using prime order subgroups instead of $F_{p}^{*}$ gives sematic security, but not security against adaptive chosen ciphertext attatcks. Therefore, ElGamal encryption (as well as RSA encryption) must use a padding scheme in order to be secure against adaptive chosen ciphertext attacks. 85.2.11.148 21:18, 22 March 2007 (UTC)

OK yes, I see the argument that the group has to be of prime order. I still think it needs a citation, though. As an aside: any idea how serious a problem this actually is? Presumably it depends on how small is the largest prime you can expect to be a factor of p-1. As a further aside: would you suggest that this be reported as a bug to developers of implementations which use F_p^*? Mbays 16:53, 23 March 2007 (UTC)

My previous comment wasn't very clear. While ElGamal over appropriate prime order subgroups is semantically secure and ElGamal over $F_{p}^{*}$ is not we should not conclude that any ElGamal implementation using the group $F_{p}^{*}$ is immediately insecure and any system using a prime order subgroup is secure. It all depends on what padding scheme is used. For example, DHAES does not require groups for which the Decisional Diffie-Hellman assumption holds and still achieves security against chosen plaintext attacks. (Unfortunately, DHAES is not exactly ElGamal, just similar. But it should make the point clear. Anyway, I'll continue to look for a better example.) Also, I haven't found a reference for the sementically secure/not semantically secure comment above. It seems to be general knowledge, however. Who is using ElGamal encryption in their implementation? 85.2.99.179 18:57, 23 March 2007 (UTC)

Would Appendix A of that paper do as a reference for the statement? Mbays 20:16, 23 March 2007 (UTC)

Yes, indeed. I didn't notice the appendix. 85.2.57.232 00:54, 24 March 2007 (UTC)

OpenPGP is an implementation that uses $F_{p}^{*}$ for ElGamal to exchange key packages. These key packages are padded using PKCS #1 encryption padding. Since PKCS #1 encryption padding adds randomness this does take care of fact that ElGamal over $F_{p}^{*}$ is not semantically secure. Using a prime order subgroup would still be slightly nicer, because then one would have a proof that the scheme is sematically secure. But at least in the case of OpenPGP it is not wrong (or at least not immediatly obvious) to use $F_{p}^{*}$. (However, I'd prefer OAEP padding instead of PKCS #1 padding.) 85.2.121.89 12:52, 24 March 2007 (UTC)

A good citation for DDH holding in certain groups would be Dan Boneh's nice survey article. The second page has a quick list of groups believed to have the DDH property. The reduction from DDH to Elgamal's semantic security (CPA) is very common and very simple. An example proof can be seen here for instance (from a site I have quite an investment in, actually!). Blokhead 05:27, 24 March 2007 (UTC)

The link to the proof looks very useful. Boneh's paper is already referenced on the DDH page. 85.2.121.89 12:52, 24 March 2007 (UTC)

I was thinking of updating the section on the security, but there is still a reference missing. In particular, I'm looking for a reference that shows that assuming the computational Diffie-Hellman assumption for a group (or family of groups) implies that inverting ElGamal encryption is hard. This statement seems easy to prove. I.e., assume we are given an oracle that on input $g,g^{a},y=g^{x},mg^{ax}$ returns $m$ Then we can use this oracle to find $g^{ab}$ given $g,g^{a},g^{b}$ as follows: Choose a random group element $r$ and call the oracle with $g,g^{a},g^{b},r$. Assume it returns $m'$ as result. Then we can compute $g^{ab}$ from $m'g^{ab}=r$. The "Handbook of Applied Cryptography" probably refers to something similar when it states that ElGamal over $F_{p}^{*}$ is believed to be secure. Unfortunately, the book doesn't make a clear statement and doesn't give a reference. 85.2.110.35 07:20, 29 March 2007 (UTC)

Some significant changes

I decided to be bold and change things up a bit. I'm currently cleaning up all of the wikipedia articles that have to do with the decisional Diffie-Hellman assumption, as part of a grander masterplan. The biggest change here so far was to migrate all of the discussion about candidate DDH groups into the DDH article, since it was repeated in several other articles as well. I'm not sure whether it would be worth it to mention (in the Security section) that many implementations (and even textbooks) use $\mathbb {Z} _{p}^{*}$ as the underlying group, though DDH does not hold there. I'm inclined to mention it, though it might also come across as confrontational. Blokhead 04:23, 15 June 2007 (UTC)

I changed the security discussion, so that it more clear that DDH is not always required for the security of the scheme. 85.2.120.114 11:25, 15 June 2007 (UTC)

Thanks for pitching in. I don't know a lot about these different padding schemes, so I'll have to read up. Right now the only comment I have is that it is possibly confusing mentioning Cramer-Shoup amid those padding schemes. I will think about a better way to mention both alternatives (padding scheme; CCA schemes "based on" ElGamal).

As for the citation about one-wayness if CDH holds, I'll look around for one, but the proof is so simple probably no one has bothered putting it in a paper ;) Suppose ElGamal is not one way (I have an adversary that inverts random ElGamal encryptions with noticeable probability), then I will construct an algorithm for CDH (with the same noticeable success probability). I get $(g^{a},g^{b})$ as input, I pick a random $z$ from the group, and give the adversary $g^{a}$ as the public key, and $(g^{b},z)$ as the ciphertext. It responds with some purported message $m$, and I output $z/m$ as my purported CDH answer. With noticeable probability, the adversary's response $m$ is the correct decryption of the ciphertext (i.e, it is such that $z=mg^{ab}$), so my CDH output is correct with the same probability. After this, I can use the random self-reduction of CDH/DDH to boost my CDH algorithm's correctness probability to very close to 1.

I don't think wikipedia is necessarily the best place for these kind of proofs. But maybe I can add it to the wiki site that includes the proof of CPA (that you just added the link to), if I can't find a reference elsewhere. Blokhead 13:59, 15 June 2007 (UTC)

I've looked for a reference for some time now without success. Putting a proof on a Cryptutor page seems reasonable to me. It might look easy, but there is still some formalism involved. 85.2.100.241 15:53, 15 June 2007 (UTC)

I looked at the DHAES paper, and I wouldn't consider it a "padding scheme", nor even claim that it's based on ElGamal. It is essentially a hybrid cryptosystem which uses Diffie-Hellman key exchange as the key encapsulation. ElGamal can be viewed as using DH key exchange as a key encapsulation for a one-time pad (both sender and receiver can compute $g^{ab}$ that they can use to mask/unmask the plaintext). But I don't think DHAES should be here in an article about ElGamal, as it doesn't really use ElGamal as a black-box. OAEP+ is fine, though we should probably re-iterate that it uses the random oracle model. Blokhead 15:32, 15 June 2007 (UTC)

Maybe Cramer-Shoup and DHAES could go int a section about related schemes. 85.2.100.241 15:53, 15 June 2007 (UTC)

Elgamal universal re-encryption

I saw an article talking about Elgamal re-encryption and Elgamal universal re-encryption, when I wanted to have more details, I did not found an article in wikipedia talking about that. Here's what is some contents of the article:

ElGamal re-encryption: Encryption(classical encryption) (c1,c2) = (m.y^r,g^r) ReRand: (c1,c2) = (c1.y^s,c2.g^s)

ElGamal universal re-encryption: Encryption (c1,c2,c3,c4) = (m.y^r,g^r,y^t,g^t) ReRand (c1,c2,c3,c4) = (c1.c3^s1,c2.c4^s1,c3^s2,c4^s2)

The aim is clear: the adversary may use the randomness used to secure semantically the encryption as a covert channel to transfer messages, though this method is not really sufficient to prevent these covert channels, because the adversary may use an unregistred key.

Key generation - error in article?

I am reading "Handbook of Applied Cryptography" (there is a free PDF online), which uses $G=\mathbb {Z} _{p}^{*}$ and states the the private key should be a random integer $[1,p-2]$. The article claims it should be (after plugging in for $q$), $[0,p-2]$. Furthermore, the book lists the same range, $[1,p-2]$ for ElGamal signatures, but the article on that on Wikipedia lists $[2,p-2]$. Basically:

	Book	Paper	Wikipedia
ElGamal encryption	$[1,p-2]$	N/A	$[0,p-2]$
ElGamal signing	$[1,p-2]$	$[1,p-1]$	$[2,p-2]$

I am also reading a research paper, "Breaking Smart Card Implementations of ElGamal Signature and Its Variants", listed as paper.

Also, the "generate a random number in *range*" bits differ. For example, in encryption, we are told to "choose a random $y$ from ${0,...q-1}$, or, in the case of $G=\mathbb {Z} _{p}^{*}$, $[0,p-2]$. Book differs.

	Book	Paper	Wikipedia
Random int in encryption	$[1,p-2]$	N/A	$[0,p-2]$
Random int in signing	$[1,p-2]$	$[1,p-1]$	$[0,p-2]$

To me it seems that encryption stuff is fragile as hell, and one mistake seems to bring the whole thing down, but here I've got three resources telling me different things. The differences don't stop at ranges - some want the random numbers to not divide $p-1$, others want them to have a GCD of 1.

Chapter 8, page 294 of "Handbook of Applied Cryptography", and Chapter 11, page 454, same book for encryption and signature, respectfully.

Deathanatos (talk) 07:37, 20 September 2010 (UTC)

Flaws in article

This article tells you to use s^-1 to decrypt, but never says how to compute s^-1. Later it says to use s', which appears to be the same thing as s^-1...? And lastly an example would be extremely helpful for understanding. — Preceding unsigned comment added by Skintigh (talk • contribs) 15:38, 8 January 2012 (UTC)

The article describes ElGamal encryption generically, i.e., without specifying the group G. But the computation of s^-1 depends on which group is used to implement ElGamal encryption. E.g. if G is the multiplicative group modulo a prime p (or a subgroup of it), then s^-1 is a modular inverse, which typically is computed using the extended Euclidean algorithm. But if G is an elliptic curve group in Weierstrass form over a non-binary field then the inverse just requires to change the sign of a coordinate. s' is indeed the same as s^-1: the definition of s' just provides one possible way to compute this value.

Personally, I think that the article would be easier to understand if ElGamal were described using one specific group G only (e.g. a prime order subgroup of Z/(Zp)^*). Not sure what other people think. 188.60.32.125 (talk) 04:39, 9 January 2012 (UTC)

I included a note about it. Lucianobello (talk) 16:22, 19 November 2012 (UTC)

Is q a prime number?

There is currently an open question whether q must be prime. In the original paper by ElGamal the group G=Z/(p) (that is the group of residues modulo a prime p) is used and ElGamal proposes to use a primitive element as the generator. Such a generator has order q=p-1, which is of course divisible by 2. So far I'm not aware of a reason why ElGamal's choice does not work other than simplifying the analysis of a protocol. I.e., if one uses a subgroup of prime order then the DDH assumption may be applicable, which can simplify things. Depending on the protocol that uses ElGamal encryption DDH may be necessary, unecessary or may not be sufficient. Hence, results that can only be obtained by using a prime order group should be added (together with a reference) to the security section. However, we should not restrict the group order in the main section, unless there is a result showing that a group order that is not prime leads to attacks. 178.195.225.28 (talk) 16:49, 29 May 2012 (UTC)

To me, it seems that that whole section needs revising and clarifying. For example, shouldn't the h=g^x be done modulo p (as in the paper?). I can't see where the description of the group is. Handheldpenguin (talk) 17:37, 29 May 2012 (UTC)

Any group G for which the DH problem is infeasible may be used. This can be G=Z/(p), but it is also possible to use a group of points on an elliptic curve. The security section discusses some constraints on G. 178.195.225.28 (talk) 05:35, 30 May 2012 (UTC)

It should be pointed out that the above remarks about Z/(p) refer to the multiplicative group of units in Z/p (very proper notation would be $(\mathbb {Z} /p\mathbb {Z} )^{\times }$), not the additive group (which is what one usually means by $\mathbb {Z} _{p}$, $\mathbb {Z} /p$, or $\mathbb {Z} /p\mathbb {Z}$).

There is generally a point in picking $x$ and $y$ as relatively prime to $q$, because if either is not then the shared secret ends up in a subgroup of $G$, thus shrinking the effective keyspace. Because an attacker who knows the factorisation of $q$ can cheaply determine the orders of $h=g^{x}$ and $c_{1}=g^{y}$ (there aren't that many possible values), this information leaks. However in the common case that $q=2r$ for $r$ a large prime, this subgroup is just as large ($r$ elements) as its complement, so committing to saying out of that subgroup also shrinks the keyspace by the same amount. In the $q=2r$ case the effect should thus only be that the keys have $1$ bit of entropy less than you'd expect. 130.243.94.123 (talk) 12:23, 15 June 2023 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on ElGamal encryption. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20090421130001/http://crypto.cs.uiuc.edu/wiki/index.php/Elgamal_encryption_scheme to http://crypto.cs.uiuc.edu/wiki/index.php/Elgamal_encryption_scheme

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 15:36, 18 September 2017 (UTC)

Possible mistake in the calculation of the inverse of s

I think there is a mistake in the second proposed way of finding the inverse of s introduced by a recent edit (18:45, 30 November 2018‎). The article is written in a general setting of cyclic multiplicative groups and not in (Z/pZ)*, thus I couldn't find a source to cite. The exponent of c1 should be (q-x) and not (q-1-x) because the order of the group is q so g^q=e by Langrange's Theorem. The editor was possibly confused and thought that we are talking about (Z/qZ)* with q prime so by Fermat's Little theorem g^(q-1)=1. It's a very confusing mistake (if indeed it is), so I hope someone could please verify and edit. — Preceding unsigned comment added by Shadysin (talk • contribs) 14:02, 6 July 2019 (UTC)

I would just comment that if this is an error, it was not introduced by my recent changes. The 24 Feb 2019 version of the article had the same formulas, in the section Efficiency/Decryption and has remained unchanged for 10 years. It looks like it was originally added by an IP user on 9 May 2009: [1] I think however that you are correct and the formula in the article has always been wrong. CodeTalker (talk) 15:23, 6 July 2019 (UTC)

Of course it was not introduced by your changes. And as you pointed out, indeed the "-1" was there 10 years ago. But at some point it was taken out (eg it's not there in [2]). I think it was reintroduced in November 2018 by an IP user ([3]). I believe it would be safe to edit the "-1" out since it seems that for the better part of the decade it was out (and some years before 2009 eg [4]) until some months ago.

That being said, we still don't have any references for this calculation, which is of course the source of the whole problem.Shadysin (talk) 10:50, 7 July 2019 (UTC)

I'm starting to think this article should be rewritten to assume the group G is just the multiplicative group of integers modulo n. The description of the system in Elgamal's original paper used integers modulo n rather than an abstract group as this article does. Most of Wikipedia's other cryptosystem articles that I've seen also use integers rather than abstract group members (RSA (cryptosystem), Rabin cryptosystem, Rabin signature algorithm, Digital Signature Algorithm, and even ElGamal signature scheme). I wonder why this one article was written this way; it seems to border on WP:OR. Rewriting it that way would give the article access to a lot more citable reference material, since AFAIK most of the relevant literature about ElGamal encryption is written using the concrete instantiation where the group members are integers modulo n and not the abstract notation used in this article. CodeTalker (talk) 21:43, 8 July 2019 (UTC)

I wholeheartedly agree, however this would be a big change and maybe more people should provide their opinion. The "Generalised ElGamal Encryption" could be kept in a final section (with some additions,eg that this formulation becomes useful for Elliptic Curve Cryptography), following closely the one reference we do have for it, namely the Handbook of Applied Cryptography, so as to avoid mistakes like the calculation of s^-1.Shadysin (talk) 17:01, 9 July 2019 (UTC)

More than just cyclic groups

This article could definitely be amended with other variants of ElGamal, such as over arbitrary finite abelian groups (as they are products of cyclic p-groups), over finite fields, and when considering elliptic curve groups over a finite fields (these are also abelian). Only mentioning cyclic groups seems reductive, and the article could definitely use some expansion given its importance. Callie Liddle (talk) 06:46, 7 October 2023 (UTC)