Hi Stephan,
>>>>>>> +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.
and why is this not an userspace policy decision on what minimum it allows? Why are we discussing this in the context of the kernel in the first place? The kernel should just expose the support for it.
Regards
Marcel
--
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
