[cabfpub] IETF input on cryptographic key lengths for Elliptic Curves

[Phillip Hallam-Baker]

So as you all know, the IETF asked the IRTF to propose a set of curves for use in TLS. The result being proposals for two curves, Ed25519 and Curve448 (aka Goldilocks). These have workfactors in excess of 2^128 (WF128) and 2^256 ()WF256 respectively.

I think these are the right sizes for current IETF protocols. WF128 provides more than enough security for any conceivable situation provided only that the algorithm is sound and WF256 provides a good margin of error if the algorithm turns out to be flawed. I do not see the need for a WF192 option since in my experience everyone goes for one extreme or the other.


One of the main advantages to the new curves as I see it is that Elliptic Curve has been ‘about to happen’ for so long now that people have given up waiting. There are so many different curves etc. that people tend to decide that the technology is not yet ready, best to wait for things to sort themselves out. The proposal for the new curves based on a different approach (rigid construction) provides a point where we can draw a line under the old stuff and move everything over to the new.

Before we can do that however, we have to specify how each of the protocols (S/MIME, SSH, TLS… ) make use of the new curves. And here we have hit a snag whose name will be familiar to many of you.

Right at the point where we have a chance to move to a new set of coherent consensus crypto we have someone arguing that ‘128 bits is enough’, do not adopt the drafts for Curve 448.


I don’t think it is enough and with modern machines I don’t see any reason to settle for the lower security curve as the upper limit on security. Curve 448 is after all as good or faster than RSA2048 on every operation. It is pretty much the same speed for public key operations and dramatically faster on private key operations.

Moving from curve P384 to Curve448 seems like a very natural and easy choice to me. Particularly if NIST approves the curve. And why not if that is the curve all the COTS applications support out of the box. Moving to Curve25519 seems like a much less attractive proposition to me.


So support in the CURDLE working group thread would be appreciated.

https://www.ietf.org/mailman/listinfo/curdle <https://www.ietf.org/mailman/listinfo/curdle>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160220/a025e54a/attachment-0002.html>