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

Fotis Loukos fotisl at it.auth.gr
Tue Feb 23 05:34:44 MST 2016


Hello,
I haven't read the discussion at the CURDLE wg mailing list, but I believe that supporting WF128 curves is becoming pretty dangerous.
We are getting pretty close to creating quantum computers that will be able to run Shor's algorithm. The number of qubits required to break a 256 bit ECC key is between 1500 and 1800, less than the number of qubits required to break a 1024 bit RSA key (2048 qubits needed). For more information you can see section 3.2 of http://arxiv.org/abs/quant-ph/0301141 by Proos and Zalka. Storage is very cheap, and thus someone can store messages and crack them at a later time. Any three letter agency will first create a 1800 qubit quantum computer and then a 4096 qubit (number of qubits required to break 2048 bit RSA key). Thus, as far as quantum computers are concerned, even 2048 bit RSA is much more secure than 256 bit ECC. We should move forward to standardizing harder to break curves than current standards.

Kind regards,
Fotis Loukos

On 02/20/2016 08:31 PM, Phillip Hallam-Baker wrote:
> 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
> 
> 
> 
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
> 


More information about the Public mailing list