# In Diffie-Hellman, are $g$ and $p$ universal constants or are they chosen by one party according to a set of rules?

I can't find any clarity on this. In textbooks, what I'm reading suggests there's already a standardized $$g$$ and $$p$$ that everyone uses, but I can't find what they are.

The closest I've come to is this RFC link.

$$g$$ and $$p$$ can be viewed as universal constants. These values are public values so the security isn't affected if an attacker knows $$p$$ and $$g$$. They also have to be the same values on both sides for a key-exchange to work.

As explained in Wikipedia (section Security):

[$$\ldots$$] For this reason, a Sophie Germain prime $$q$$ is sometimes used to calculate $$p = 2q + 1$$, called a safe prime, since the order of $$G$$ is then only divisible by $$2$$ and $$q$$. $$g$$ is then sometimes chosen to generate the order $$q$$ subgroup of $$G$$, rather than $$G$$, so that the Legendre symbol of $$g^a$$ never reveals the low order bit of $$a$$. A protocol using such a choice is for example IKEv2.

So these are infact default values, for example the Java documentation (might be outdated for 2019) lists the following values for 512-bit keys:

p = fca682ce 8e12caba 26efccf7 110e526d b078b05e decbcd1e b4a208f3
ae1617ae 01f35b91 a47e6df6 3413c5e1 2ed0899b cd132acd 50d99151
bdc43ee7 37592e17
g = 678471b2 7a9cf44e e91a49c5 147db1a9 aaf244f0 5a434d64 86931d2d
14271b9e 35030b71 fd73da17 9069b32e 2935630e 1c206235 4d0da20a
6c416e50 be794ca4


Normally such default values are used, but it is also possible to choose new $$p$$ and $$g$$ values if you want to.

• Java still uses the DSA defaults for DH as well, and Java 8 adds 2048-bit and 9+ 3072-bit, but to be clear the DSA defaults are not and cannot be safe primes p=2q+1 but instead Schnorr primes p=rq+1 for much larger r and smaller (but large enough) q. – dave_thompson_085 Mar 7 at 4:43

For Alice and Bob to do a key agreement, they must agree in advance on the group and generator. The group and the generator will have been baked into the software that Alice and Bob and everyone else use, like the standard web browser and the standard web server.

In finite-field DH, the group and generator are determined by the prime $$p$$ and the base $$g$$. Modern Diffie–Hellman doesn't use finite fields at all: modern systems like X25519 use elliptic curves. You should use X25519 if you are engineering a modern system!

But if you are talking about finite-field DH, you are correct that RFC 3526 provides the standard groups that everyone ought to use, chosen according to standard security criteria by the semi-rigid process described in RFC 2412. The standard security criteria include using a safe prime $$p = 2q + 1$$ for some prime $$q$$, chosen so that $$p \equiv 7 \pmod 8$$ so that $$g = 2$$ is a quadratic residue and thus has large prime order $$q$$. Using a semi-rigid process like this is important to give confidence that the group was not maliciously chosen to have a back door.

• Web means TLS, and while agreeing ECDH is better, if you want FF/classic/integer/Zp/modp DH in TLS1.3 you must use the groups in rfc7919, created by the same process as 2412/3526 but with different constants (see section 8.5 for handwaving). In TLS1.2 and below you can use these groups if 7919 is implemented; otherwise client usually can't be baked because server sends explicit params of its choice in ServerKX message (signed by server), while server can be baked but in practice often is configurable. – dave_thompson_085 Mar 7 at 4:26
• I concede that TLS 1.3 did something silly in contravention of my clearly stated and justified advice. I also concede that TLS<1.3 did much sillier things like allowing dynamic group negotiation or stupid choices of groups. You should still use RFC 3526 if you're doing the silly thing of making a new application of finite-field DH. After all, the only reason RFC 7919 doesn't use the RFC 3526 groups is to…not use the same groups as other protocols! – Squeamish Ossifrage Mar 7 at 4:33