Re: ECDHE security level

On 10 October 2014 11:49, Brian Smith <brian@briansmith.org> wrote:
> On Fri, Oct 10, 2014 at 10:13 AM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
>> Brian Smith noted some minor issues with the use of security level to
>> specify minimum ECDHE curve size.  Primarily, security level is based
>> on an evaluation of the curve, which can change over time (usually it
>> decreases).  If we intend to specify a 128 bit security level, we
>> might technically exclude the NIST P256 curve if there is a
>> cryptanalytic advance.  Secondly, if the CFRG chooses to bless 25519,
>> then it would be foolish of us to exclude what is a perfectly good
>> curve; currently it is considered to have a security level of ~126
>> bits.
>>
>> The intent of this requirement was to avoid intentionally weak curve
>> choices from being used, not to generate potential ambiguity.
>>
>> So, I'm going to propose that we simply reduce the minimum to 112
>> bits.  At 112 the elliptic curve is still stronger than the finite
>> field Diffie-Hellman minimum of 2048 (TLS 1.3 doesn't even permit the
>> use of something that weak).  ECRYPT II estimates that 112 is good
>> until around 2030, and equivalent to 2432-bit finite field DH.
>
> I suggest that you avoid the subjective "security level" concept
> completely and just say that that an ECDSA and ECDHE keys must be at
> least 256 bits, and that an DHE, RSA, and DSA keys be at least 2048
> bits. I'm actually not sure you want to have that limit for DHE keys,
> but it seems like a good idea to have such a requirement for RSA keys.
> Specifying a minimum ECC key size in the draft actuallly have very
> little practicle effect since almost nobody is using ECC key sizes
> less than 256 bits, but specifying the minimum RSA modulus size would
> be a practical benefit, because quite a few servers are still using
> 1024-bit keys.
>
> As you noted, "security level" is assessed differently by different
> organizations. Also, as you noted, 224-bit ECC keys are commonly
> assessed at the 112 bit security level, but you're not really
> intending for 224-bit ECC keys to be acceptable.

If we intend to permit 25519, then we'll need to permit something
lower than 256.  I don't see any reason why permitting ECC keys of 224
bits is a problem, do you?

Received on Friday, 10 October 2014 18:55:59 UTC