# Elgamal with secret key equal to zero possible?

From various sources (e.g. this paper, page 3), the key generation algorithm of Elgamal samples the secret key $x$ from $\mathbb{Z}_q$, which is identifiable to $\{0, 1, 2, \dots, q-1\}$.

My question is: what happens when the sampled $x$ is, say, zero? Indeed, in this case, the public ley $h$ is equal to 1, and encrypting plaintext $m$ with randomness $r$ yields $(g^r, m)$. This seems to me like a serious issue. The same happens with $x = 1$. In this case $h = g$, it is easy to notice that $h$ is equal to $g$ and deduce that the secret key is $1$.

Of course,this "methodology" does not extend to any value of $x$ (testing whether $g^x$ is equal to the public key), since this is pretty much a brute force attack, by assumption computationally infeasible. I also understand why the scheme can be proven secure, though: because $q$ is so large that the case $x = 0$ or $x = 1$ happens with a negligible probability. Yet, in practice, it can happen... Do implementations take that into account?

• You could use your argumentation for any fixed value $x$, say $x=288878347584375$. If the public key has this value $y=g^x$, then you know the secret key $x$. The point is that the keyspace is so large that this does not matter (because fixing any value will be hit with negligible probability). Consequently, you can safely ignore this problem and define $x$ to be the entire $\mathbb{Z}_q$. Clearly, this assumes that you are able to sample uniformly at random, i.e., have good randomness available at key generation - but in theory you assume this to be true. – DrLecter Apr 29 '16 at 11:51
• Funfact: this is probably one reason why it is mandated by EdDSA (IIRC) to always set up the MSB of the secret key. – SEJPM Apr 29 '16 at 12:12
• You could wonder if it wouldn't be better to generate an all zero value and detect that there is a problem instead of generating a 1 and all zero's, which is equally insecure and doesn't show this issue. Having the implementation test for 0 and 1 and then break off with a strong warning that the PRNG is broken seems to be the best option. If the RNG was already tested you could just let it be. – Maarten Bodewes Apr 29 '16 at 13:09
• @SEJPM: actually, DJB sets the MSB of the secret key to be 1 so that implementations wouldn't be tempted to "optimize" things by skipping higher order 0 bits in an attempt to make things go faster (and add a timing side channel); he wasn't seriously concerned about someone using the all-0 key... – poncho Apr 29 '16 at 13:32
• @SEJPM In fact, the Ed25519 paper argues against the "weak keys" misconception: "We could declare that $0B$ and $37B$ are 'broken' by these two 'attacks' and that users must check for, and reject, these 'weak keys'; but the same confused logic would require rejecting all keys in all cryptosystems, and would have no relevance to the standard definition of signature security." – yyyyyyy Apr 29 '16 at 19:00

It's worse than that: if $$x = 1283767$$, then the ciphertext will be $$(g^r, m \cdot g^{r \cdot 1283767})$$, which an adversary can immediately detect by checking whether $$h = g^{1283767}$$ and subsequently exploit to decrypt messages! The same trick works for $$x = -1$$, $$x = 42$$, and $$x = 123456789$$.
We pick $$q$$ and $$g$$ so that the space of values for $$x$$ is so large that if we choose $$x$$ uniformly at random, the adversary's probability of success at guessing it is negligible, below $$2^{-128}$$—so small that you should be more worried about cosmic rays flipping bits in your RAM than you are about this event.
There are much better attacks recovering $$x$$ from $$h = g^x$$, requiring you to choose $$q$$ to have thousands of bits. You should be much more worried about how you're using Elgamal encryption and how you shoehorn arbitrary messages in your application into integers mod $$q$$, and even more worried about articulating higher-level application security goals.