Am Mittwoch, 2. März 2016, 08:03:44 schrieb Sandy Harris:
Hi Sandy,
> Salvatore Benedetto <salvatore.benedetto@xxxxxxxxx> wrote:
> >> > > > +static int dh_check_params_length(unsigned int p_len)
> >> > > > +{
> >> > > > + switch (p_len) {
> >> > > > + case 768:
> >> > > > + case 1024:
> >> > > > + case 1536:
> >> > > > + case 2048:
> >> > > > + case 3072:
> >> > > > + case 4096:
> >> > > > + return 0;
> >> > > > + }
> >> > > > + return -EINVAL;
> >> > > > +}
>
> As far back as 1999, the FreeS/WAN project refused to
> implement the 768-bit IPsec group 1 (even though it was
> the only one required by the RFCs) because it was not thought
> secure enough. I think the most-used group was 1536-bit
> group 5; it wasn't in the original RFCs but nearly everyone
> implemented it.
>
> >> And besides, I would like to disallow all < 2048 right from the start.
>
> I'm not up-to-date on the performance of attacks. You may be right,
> or perhaps the minimum should be even higher. Certainly there is
> no reason to support 768 or 1024-bit groups.
>
> On the other hand, we should consider keeping the 1536-bit
> group since it is very widely used, likely including by people
> we'll want to interoperate with.
Considering the recent attacks which kind of broke DH <= 768, all smaller than
1024 is not to be used any more. Even 1024 bit is not too far off from 768 so
I would consider not using 1024 to keep a safety margin.
It is widely suggested to use 2048 and higher. But for compatibility, I agree
with 1536.
However, that leaves us with the open question for the upper bound. I have no
idea which sizes hardware may implement. But considering that OpenSSH uses DH
up to and including 8192 these days (see /etc/ssh/moduli), I would suggest to
allow 8192 too.
In addition, we should all be prepared to increase the limit with a reasonable
effort. Thus, if we have implementations covering hardware support, they
should cope with reasonable efforts.
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
