
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">So support in the CURDLE working group thread would be appreciated.</div><div class=""><br class=""></div><div class=""><a href="https://www.ietf.org/mailman/listinfo/curdle" class="">https://www.ietf.org/mailman/listinfo/curdle</a></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>