7
$\begingroup$

There is a plethora of elliptic curves that are close to the 256-bit security level (i.e., fields and groups of approximately 512 bits). Examples are Curve448, P-521, Brainpool-P512.

The standard rationale for 256-bit symmetric ciphers is to protect against Grover's algorithm, which would halve the security level. However, in such a post-quantum setting, Shor's algorithm would destroy both 256-bit curves (with 128 bit security, e.g. Curve25519 or P-256) and 512-bit curves.

In the pre-quantum setting, breaking 128 bit security is most probably out of reach for mankind, and 256 bit security is astronomically further away.

Seemingly, neither post-quantum nor pre-quantum worlds have any benefit to using elliptic curves that achieve more than the standard 128 bit security level, then what is the point of their existence and their standardization?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
7
$\begingroup$

what is the point of their existence and their standardization?

I would agree with your assessment; I also don't see the point of nonspecial [1] curves significantly larger than 256 bits.

However, based on my observations, I see two attempted justifications:

  • What if someone found a 'weakening' of the elliptic curves (but not to a point that they're totally broken); a 256 bit curve might become weak, but a circa 500 bit curve might retain enough strength.

  • Some people have a superstition about 'mismatched cryptography' - if one part of your system has '256 bits of security', then all your components ought to have 256 bits of security, otherwise, well, perhaps you'll end up misleading people about how strong your system is (or something).

I don't personally consider either argument that persuasive, but that's what I've heard...

[1]: I'm not counting pairing friendly curve (which need to be somewhat larger to account for recent attacks) or curves used for supersingular isogenies; you're also not thinking of those cases; just thought to be thorough...

Improve this answer
$\endgroup$
6
  • $\begingroup$ Ah, I did not take pairings into consideration. That's a useful clarification. On the other hand, the curves I mention are not pairing friendly, as far as I know. $\endgroup$
    – Ruben De Smet
    Jul 18, 2022 at 17:40
  • 2
    $\begingroup$ I consider keeping to a specific classic security level logical, as you could use the same "weakening" argument for any part of the system. Moreover, it allows you to define 2 security levels to which all algorithms must allow in flexible systems like TLS (which TLS 1.3 took advantage of, while TLS 1.2 allows for many, many cipher suites that do not bring any specific benefit); software complexity in itself costs a lot, both with regards to security, development and of course testing / maintenance. $\endgroup$
    – Maarten Bodewes ♦
    Jul 18, 2022 at 22:22
  • $\begingroup$ I think your comment would count as a distinct answer, Maarten? If you took the time to write one, I would greatly appreciate a little note on how a 256-bit curve (with 128-bit security) matches a 128-bit symmetric cipher in a case like TLS. $\endgroup$
    – Ruben De Smet
    Jul 19, 2022 at 12:24
  • 2
    $\begingroup$ @RubenDeSmet: actually, with TLS, the ciphersuite doesn't bind to a specific curve; that is negotiated separately. For example, in TLS 1.2, the ciphersuite may state that an ECDHE operation will be used, however it doesn't say which curve it is over. You may decide to use a 256 bit curve with a 128 bit ciphersuite; however that is your choice, not TLS's $\endgroup$
    – poncho
    Jul 19, 2022 at 12:40
  • 1
    $\begingroup$ @SAIPeregrinus: actually, there are symmetric systems where multitarget attacks don't apply, and there are asymmetric systems where they do. In any case, for both systems, we can say that if the best attack takes about $2^\lambda$ operations (for some reasonable definition of 'operation'), then it has about $\lambda$ bits of security - other than the different definitions of 'operation', the same concept would appear to apply to both symmetric and asymmetric... $\endgroup$
    – poncho
    Jul 21, 2022 at 13:08
0
$\begingroup$

For JWT tokens, ES512 is relatively common. But I ran into this, where if you want to share a certificate that's used by TLS, then you get stuck with ES256. I thought that TLS used to have the larger curve, and it got removed as "excessive". I just picked ES512 for my tokens because I had read that P-256 has some weakness. The fact that 512 is "excessive" indicated that maybe that's what I should be using. I did notice that if I didn't cache such tokens that my profiler was showing me that the CPU was getting monopolized doing a big.Int divide operation. So legitimate operations can be slow; but it was perfectly fine for my uses, since I cached tokens while they were unexpired.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Huh, what? Certainly not for the certificates? Do you mean the key agreement part? Yeah, that's not super surprising as the available curves don't get established beforehand in TLS 1.3, so if you'd use ECDH with a 521 bit curve you might have to retry, which is not what you want. $\endgroup$
    – Maarten Bodewes ♦
    Jul 18, 2022 at 22:30
  • 1
    $\begingroup$ I was using JWTs as ES512 for existing JWT token code inside the http sessions; I wanted to simplify the setup as the TLS key is also a signing key. I had to downgrade to making ES256 JWTs to be able to share the same keypair, by extracting the keypair from the x509 cert. I had found myself down a rabbit-hole, reading that larger curves were in the standard at one point, but taken out as "excessive". $\endgroup$
    – Rob
    Jul 18, 2022 at 23:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.