In Diffie-Hellman there is a large integer which is prime, but the other one needs not be large, and it needs not be prime either.
With DH, computations are done modulo a big prime p. A generator called g is also used: g "generates" the values gi mod p. If you (virtually) compute the gi modulo p, you will get back to 1 at some point; the smallest non-zero value i such that gi = 1 mod p is called the order of g (let's write it r). Necessarily, r divides p-1.
What DH needs is that:
- p is large enough to make discrete logarithm hard; say, at least 1024 bits (current fashion is 2048 bits, because 1024 bits are now considered to be "a bit too weak" as in "unbreakable for now, but maybe in 20 years...").
- r must have at least one prime factor q which is large enough to deter discrete logarithm; in this context, this means at least 170 bits (there again, fashions dictate 256 bits -- cryptographers just love powers of two).
q and r needs not be known by the people who do the DH. If you select a random p of appropriate size, and a random g (as a value between 2 and p-2, inclusive), then g will be fine with overwhelming probability (you will not know r, let alone q, but it would be extremely improbable that all prime factors of r are short).
Nevertheless, you could try a bit harder in the choice of p; for instance, you could select p such that p = 2t+1 where t is also prime. At this point, any g (between 2 and p-2) is guaranteed to have an order equal to either t or 2t, so you can choose g as you see fit. In particular, you can choose g = 2, which makes computations a bit faster.
None of the values above need to be secret. Indeed, both DH parties are assumed to know them beforehand, so they cannot be secret (if they were secret, it would be a shared secret and you would not need to do Diffie-Hellman at all, you could just use that shared secret as is). To save effort, you could reuse existing, published values for p and g, for instance these values.