> Could an international, decentralized curve be constructed by standards bodies from several geopolitical adversaries such as US, China, Russia and Turkey all simultaneously issuing 1 point each to create a combined 4-point curve, so that no single standards body has opportunity to purposely make the result insecure?
The process would be a little more complicated than simply choosing 4 points, but yes you could do something close enough to this in theory.
In actual practice there's really only two sets of curves most people [0] implement, and just about everyone agrees to use:
- The NIST p curves
- Curve25519/Curve448 by Bernstein &c.
Which you use tends to fall on what side of the crypto divide you fall on:
- NIST p curves if you care about governmental compliance such as FIPS
- Bernstein &c's curves if you care about security and distrust NIST created curves.
I personally fall on the latter side but spend most of my time doing software for the former. :) A promised later revision to FIPS will standardize Bernstein &c's curves.
Almost nobody implements negotiating arbitrary curves. That's really unsafe.
So, as 'tptacek would say... just use Curve25519.
[0]: I'm talking about major software such as TLS, VPNs, SSH, Kerberos... etc.
There are all sorts of pitfalls and potential attacks even if the curves are truly random[1]. Some curves also require you to verify whether public keys are valid points on the curve (and their security breaks if you don't do so). So they're harder to implement safely. Others are hard to implement in a way that avoids timing attacks.
This is one of the reasons more paranoid people have generally preferred Curve25519 over the NIST curves -- the NIST curves have very arbitrary base point values which (in theory) could have been backdoored. NIST later published a proof that if you hashed some other arbitrary values, you get the base points -- but then the follow up question is where did the other arbitrary values come from.
It's misleading to claim that 25519 pubkeys don't require validation: In some applications validation isn't required, in other applications validation is simpler but still required.
Marketing bullet points aren't a replacement for careful cryptographic review.
The process would be a little more complicated than simply choosing 4 points, but yes you could do something close enough to this in theory.
In actual practice there's really only two sets of curves most people [0] implement, and just about everyone agrees to use:
- The NIST p curves
- Curve25519/Curve448 by Bernstein &c.
Which you use tends to fall on what side of the crypto divide you fall on:
- NIST p curves if you care about governmental compliance such as FIPS
- Bernstein &c's curves if you care about security and distrust NIST created curves.
I personally fall on the latter side but spend most of my time doing software for the former. :) A promised later revision to FIPS will standardize Bernstein &c's curves.
Almost nobody implements negotiating arbitrary curves. That's really unsafe.
So, as 'tptacek would say... just use Curve25519.
[0]: I'm talking about major software such as TLS, VPNs, SSH, Kerberos... etc.