RSA key configuration limitations

[James Ralston]

On Mon, Jun 13, 2022 at 4:34 AM Jochen Bern <Jochen.Bern at binect.de> wrote:

> On 10.06.22 16:50, Dmitry Belyavskiy wrote:
>
> > There is a need to increase RSA key requirements to make the
> > installations more secure. Just updating the default compiled-in
> > value isn't an option because it may significantly break legacy
> > systems compatibility. This PR [1] introduces a new configuration
> > option MinRSABits to be managed for security's sake.
> >
> > If this approach is OK for upstream, please let me know and I will
> > improve this PR according to the feedback.
>
> I realize that with the *current* selection of algorithms available
> in OpenSSH, fine-grained control of minimum key size almost(!) is an
> RSA-only topic, but nonetheless I wonder whether newly-defined
> config syntax thereto should be aimed at extensibility to other
> cryptalgorithms ...

That ship sailed long ago:

$ grep SSH_RSA_MINIMUM_MODULUS_SIZE sshkey.h
#define SSH_RSA_MINIMUM_MODULUS_SIZE    1024

It’s not worth it to attempt to refactor this approach, as with both
the ecdsa family and ed25519, the cipher name specifies the security
strength.

Dmitry’s merge request both defaults MinRSABits to
SSH_RSA_MINIMUM_MODULUS_SIZE, and prohibits setting MinRSABits to
anything less than SSH_RSA_MINIMUM_MODULUS_SIZE.  So unless the
administrator specifically sets MinRSABits to something greater than
1024, it will not change the behavior of OpenSSH.  It also documents
MinRSABits in the man pages, and includes MinRSABits in “ssh -G”
output.  All of this seems perfectly reasonable.

NIST Special Publication 800-131A (1) prohibits the use of RSA keys
with len(n) < 2048 for all uses but legacy digital signature
verification, and an increasing number of sites (including ours) must
comply with NIST SP 800-131A.  Having the MinRSABits option would make
our lives easier with respect to compliance.

(1) https://doi.org/10.6028/NIST.SP.800-131Ar2