On Wed, Jun 15, 2022 at 5:33 AM James Ralston <ralston at pobox.com>
wrote:
> 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.
>
I also need to adjust tests.
> 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
Yes, and this was a part of my (unwritten) rationale :)
--
Dmitry Belyavskiy