Re: ECDHE security level

On Fri, Oct 10, 2014 at 12:13 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> On 10 October 2014 12:06, Brian Smith <brian@briansmith.org> wrote:
>>
>> I do think that things should be specified in such a way that
>> Curve25519 would be acceptable. (I overlooked that the Curve25519 key
>> is not considered to be 256 bits long.) My main point is to try to
>> avoid "security level" because that's not a well-defined and
>> well-agreed-upon concept. I don't see why saying "224 bit keys" is
>> better than saying "250 bit keys" or "225-bit keys" unless the
>> intention is specifically to allow 224-bit ECC keys.
>
> Would 224-bit ECC be unacceptable in your mind?  All the sources I
> have found consider it to be stronger than 2048 finite field.  Isn't
> that the only relevant concern?  If no one actually implements and
> deploys it, that's no big deal.  Especially if everyone is using
> 255/256 bits.

With my suggestions in the pull request, I was not intending to have
the spec changed so that 224-bit ECC is considered acceptable. I
merely wanted the language fixed so that P-256 and Curve25519 and
others were not forbidden on an unintended technicality, and so that
no ambiguous terms like "security level" were used.

My own opinion is that we tolerate RSA-2048-PKCS#1 only because we
have no other choice, due to legacy concerns, IPR FUD, and RSA's poor
performance. For that, and other reasons, whether 224-bit ECC is "good
enough" should be determined independently of what we tolerate with
RSA. I think there are some technical and non-technical reasons why it
would be difficult to get P-224 to actually be deployed in a
widespread manner. I also think there are better alternatives to the
224-bit curves I know of. Consequently, I'm not sure it is worth
spending time debating the suitability of 224-bit ECC.

Cheers,
Brian

Received on Friday, 10 October 2014 19:58:48 UTC