> If you try to select your own parameters you're probably going to pick wrong, either in the sense of breaking the crypto

Is there any known situation in which generating parameters with 'openssl dhparam' will give you broken/weak parameters?

> either in the sense of breaking the crypto or making people wonder if you selected your parameters to hide a backdoor

This is a concern if you're going to distribute your parameters with software, but it could make sense where a sysadmin controls both endpoints, such as a site-to-site VPN.

This is a newbie question, but how are the standard primes created? How is it ensured that they are not selected maliciously, etc?

(a link will suffice)

The standard prime groups have their highest and lowest 64 bits set, and as many as possible of the rest taken from the binary expansion of pi. The group #14 prime for example is

p = 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }

The value 124476 is the smallest non-negative value which results in p and (p-1)/2 both being prime and 2 being a quadratic residue mod p; this ensures that the subgroup {2^0, 2^1, 2^2, 2^3, ... } is cyclic.

We assume that the binary expansion of Pi is not selected maliciously. ;-)

And as an amusing tidbit, here is the actual value in hex:

      FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
      29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
      EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
      E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
      EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
      C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
      83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
      670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
      E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
      DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
      15728E5A 8AACAA68 FFFFFFFF FFFFFFFF

Source: https://tools.ietf.org/html/rfc3526#section-3

> We assume that the binary expansion of Pi is not selected maliciously. ;-)

Well, I suppose that we must assume that, as assuming otherwise is self-defeating: anyone running the simulation we're living in already has direct access to the plaintexts anyway.

That somebody maliciously caused the circle's circumference to diameter ratio to be insecure in this application is indeed not an issue.

However, a possible danger is that somebody maliciously suggested using π instead of e...

True, but Pi is pretty much tradition now... enough so that when Decorrelated Fast Cipher used e instead, it raised some eyebrows.

> (a link will suffice)

https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number

pretty good presentation on that by djb: https://projectbullrun.org/surveillance/2015/video-2015.html...

Are there reasons other than speed/resource-usage for not using 15-18? Or put another way do you prefer group #14 above all others or is #14 the lowest level of security you are comfortable with?

Speed is the main reason. Going bigger doesn't gain you anything; in some cases it may lose you something since slower arithmetic makes it possible to exploit lower-bandwidth side channel attacks.

> > Don't use out-of-the-box Diffie Hellman params

> Wrong answer. Standard primes are fine; just avoid the small ones.

Sure, that's what I meant insofar as the out of the box params are apparently too small in many apps/libs. The links I gave cover it pretty well, I think, no?