Is it considered worth it to replace OpenSSH's moduli file?
Exchange/Selection process
Why remove primes shorter than 2000 bits? According to RFC4419, the key exchange starts with the client sending its preferences to the server in the form of 3 numbers:
- the minimum acceptable modulus length,
- the maximum acceptable length
- and the preferred length.
Then the server chooses a random prime that best satisfies this requirement.
In practice (at least with OpenSSH 6.7), the client's minimum and maximum is always 1024 and 8192. The preferred length is 8 times the security level of the symmetric cipher. The server then chooses like this:
- it discards the primes outside the min-max range,
- then it picks the shortest available length that's not less than the preferred length
- finally, it chooses one randomly out of those.
With AES-128, we end up with an 1024 bit modulus which is more like 2^80 effort to break. (It's not linear, you can't just multiply by 8.)
Why regenerate?
Why regenerate the file from scratch? To quote RFC4419:
The use of multiple moduli inhibits a determined attacker from
precalculating moduli exchange values, and discourages dedication of
resources for analysis of any particular modulus.
This has been demonstrated in the Logjam attack.
It is not as effective if everyone uses the same moduli file distributed with the SSH package. For this reason, I generated different moduli files on every host.
Note: modern SSH uses elliptic-curve Diffie-Hellman, which is more secure in theory.
If you want to generate new non elliptic-curve primes do this:
ssh-keygen -G moduli-2048.candidates -b 2048
ssh-keygen -T moduli-2048 -f moduli-2048.candidates
Then replace the contents of your moduli (usually /etc/ssh/moduli) file with the contents of moduli-2048
The ssh-keygen options -G and -T seem to be obsolete.
According to man ssh-keygen, in the MODULI GENERATION section, the current commands are:
ssh-keygen -M generate -O bits=2048 moduli-2048.candidates
ssh-keygen -M screen -f moduli-2048.candidates moduli-2048