6

Currently it's recommended to do something about the contents of /etc/ssh/moduli. I've seen two ways:

  • to strip all moduli of less than 2047 bytes size from the file.
  • to recreate them using ssh-keygen.

The first is a very quick fix, and immediately should improve security. On the other hand, i don't know if there's any extra issue for the remaining ones lurking that we'll find out about in a few months. Thus I at least want to gather the exact way for regenerating /etc/ssh/moduli using ssh-keygen.

The man page says the following:

 By default, each candidate will be subjected to 100 primality tests.
 This may be overridden using the -a option.  The DH generator value will
 be chosen automatically for the prime under consideration.  If a specific
 generator is desired, it may be requested using the -W option.  Valid
 generator values are 2, 3, and 5.

 Screened DH groups may be installed in
 .../etc/ssh/moduli.  It is important that this file con-
 tains moduli of a range of bit lengths and that both ends of a connection
 share common moduli.

I wonder what "screened" means in this context. Does it mean you ran 

  ssh-keygen -T moduli-length-f moduli-length.candidates

against a file created using -G ? Or does it mean you have someone (who happens to be a group of crypto specialists with supercomputer in reach) look at them with more sophisticated methods?

It's so extremeley vague, I'm unable to tell what they mean. To make it worse, I haven't found any distro having documented how they make the moduli set for their own SSH package. I guess it takes days if they include 8k ones and so they're just happy to be done with it - but it doesn't instill confidence either. So I'd really love to get a handle on this.

If you wondered: The difference between 2 and 5 might be described here: What is the difference between Diffie Hellman generator 2 and 5?

But actually, the manpage says 'the DH generator' which could be either 2 or 5. Awesome.

Improve this question

1 Answer 1

Reset to default
2

"screened" means "has been verified to be good and strong and not deliberately weakened, by somebody who knows what this means". In practice, this means that the parameters have been generated with a NUMS method.

Improve this answer
3
  • Good old "nothing up my sleeve" parameters.
    – Mike Ounsworth
    Commented Jun 5, 2015 at 20:17
  • This seems to be an evasive answer. Would you assume that the method invoked when running ssh-keygen -G and then verifying using -T has seen sufficient verification? or would one i.e. need to run a lot more verification rounds because the default of 100 is too low for larger keys? etc. (don't need to literally answer to this command-related example - but I'd appreciate if you tried not having lose ends in the answer)
    – Florian Heigl
    Commented Jun 5, 2015 at 21:50
  • 4
    The "verification" is not a question of a number of rounds; we do not fear to hit weak parameters out of bad luck, but out of malice. If you use ssh-keygen and if you assume that ssh-keygen performs an honest parameter generation, then the parameters are fine. Indeed, producing your own random parameters is the most realistic method of "screening". Now, of course, this moves the issue to one of auditing ssh-keygen's source code and, preferably, compiling it yourself (and then check the compiler, and the OS, and so on).
    – Thomas Pornin
    Commented Jun 6, 2015 at 12:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .