# How to obtain 256-bit security from Ed25519?

It is said that breaking Ed25519 has similar difficulty to breaking RSA with ~3000-bit keys" 1

When using RSA, I prefer 4096-bit keys, but I would like to use Ed25519.

If I wanted to double the security level - similar to RSA with ~6000 bits - what are my options?

Do we have to wait for a new standard to be published?

Could we easily hack libsodium/nacl in the mean time?

• I'd worry far more about quantum computers and mathematical advances in elliptic curve discrete logarithm solving than about the 128 bit security level of Ed25519. – CodesInChaos Jul 5 '16 at 11:18

## 2 Answers

It is not possible to double security level of Ed25519 any trivial way. Instead, doubling security level requires using another curve that is approximately 512 bit curve.

In systems compliant with RFC 7748, i.e. some of IETF specifications, there is Curve448 curve (Ed448-goldilocks). It is almost twice as strong as Curve25519 (its strength is 224 bits). This is often convenient alternative, because it is already available on some of the systems.

Widely deployed alternatives that are 256-bit security: Of course there are also BrainpoolP512 and NIST P-521 curves, which in theory provide 256 bit security. However, BrainpoolP512 and NIST P-521 are not considered to be as good as Ed25519 in all aspects possible (see e.g. https://safecurves.cr.yp.to/).

M-511 and E-521 are curves similar to Curve25519, which offer around 256-bit security level. However, because it is wide spread to consider security level 128 - 192 sufficiently strong for now, so larger curves are not used often in practice. For instance, NSA suite B site suggests that they consider 192-bit security level (i.e. 384-bit elliptic curves) to be sufficient to protect TOP SECRET materials.

Any optimized curve specific implementation of elliptic curves, such as the implementation of Curve25519 in lib sodium/NaCL is hard to replace efficiently with curve of different size. However, the API level of lib sodium/NaCL allows easy replacement of cryptographic primitives. Therefore, the "right" way to "hack libsodium/NACL" would probably be to provide the necessary curve(s) implementation(s) in API that is compatible with NaCL API. This usually requires use of different implementation rather than tweak of code implementing Curve25519. And some API work to adapt the API, as most Elliptic Curve implementations have APIs somewhat different from API in libsodium/NaCL.

• Focussing on the question as written, it would probably be easier for a non-cryptographer to hack Ed25519 code to use M-511 than Ed448-Goldilocks, because the curve has the same form (y^2 = x^3 + ax^2 + x). Not, of course, that it's a good idea for non-cryptographers to hack crypto code. – Peter Taylor Jul 5 '16 at 8:48
• @PeterTaylor I tend to agree, so I added mention on the answer about M-511, and E-521 which are "twice the security level". However, I feel that currently Ed25519 should be sufficient for nearly anything, and if it is necessary to go beyond that, it is really not necessary to double the security level. Especially as security level is really about $O(2^n)$. I.e. in this case it is expected to take 340282366920938463463374607431768211456 times the same time to brute force. Something take merely 4951760157141521099596496896 times the time, but apparently more widely deployed likely is better. – user4982 Jul 5 '16 at 18:55
• I was thinking more in terms of a Montgomery curve requiring fewer code changes than in terms of security level. M-383 would also fit at the ~192-bit level. – Peter Taylor Jul 5 '16 at 19:43
• Kind of true. However, I think the algorithm agility in NaCL is better on API level, rather than code level. I added this detail to my answer. – user4982 Jul 6 '16 at 0:04

When using RSA, I prefer 4096-bit keys, but I would like to use Ed25519.

If you use Ed25519 (which is based on Curve25519), well, there's not a great deal you can do; you can find discrete logs for Curve25519 with about $O(2^{128})$ effort, and performing a discrete log allows you to recover the Ed25519 private key.

Now, you could replace Curve25519 with a stronger curve; however quite frankly it doesn't sound like you know enough to do that securely.

Also,

If I wanted to double the security level - similar to RSA with ~6000 bits

In what sense does increasing the RSA modulus from 3000 bits to 6000 bits "double the security"? It doubles the number of bits; however it doesn't come close to doubling the log effort required by NFS to factor.

• I have removed the remarks above... – Maarten Bodewes Jul 4 '16 at 21:27