Hi, I heard that following logjam (which I'm a coauthor of), haproxy has changed its default set of primes.
That's a good start. However you give no information as to *how* you generated the primes (correct me if I'm mistaken -- I just didn't see such a thing in the commit log, but haven't searched further). This is a problem. The recommended practice is to generate primes a reproducible fashion. Example 1: the Oakley primes are generated as follows (IIRC -- I haven't checked back): p = 2^768-2^704 + 2^64-1 + 2^702*(floor(pi)+i) is a safe prime, with i smallest such that this holds (safe prime means (p-1)/2 prime too). Fictitious example 2 to generate a 1024-bit prime: take an integer seed i, and concatenate SHA256(i)||SHA256(i+1)||SHA256(i+2)||SHA256(i+3) such that the 1024-bit concatenation is a safe prime (e.g pick smallest such i). There's also a prime generation process in FIPS 186-3. Why does this matter ? Because the cost of attacking DLP mod p is not uniform across all primes p (even safe primes). There's a class of "special primes" for which the attack is easier. Easy-to-spot primes in this class are those of the form 2^n-c for instance. But the class, despite being completely negligible in weight, is somewhat broader. There is a way to generate a prime within this class (and know the trapdoor -- in fact you generate the trapdoor first), without someone being able to see the quirk (even significant computing power would not detect it). Now you say: "this bitstring is random, and it is prime". Should I trust you ? You should first convince me that it is really an innocent bitstring. A paranoid user would believe that it has been generated by (say) NSA, which convinced you to claim that it's random material -- the secret goal being to foster the use of weak primes. Hope this helps, E.
