NIST 有“定义”的 15 条“标准曲线”，在FIPS 186-4中指定。实际上，他们并没有自己定义它们；他们从SEC继承了它们。这 15 条曲线聚合为 3 组：
- P-* 曲线在“素数域”中工作（点坐标是以素数p为模的整数）。
- B-* 曲线在“二进制域”中工作（点坐标是GF(2 m )中的值）。
- K-* 曲线与 B-* 曲线在相同的领域工作，但具有允许更快计算的特殊结构。
NIST 发现，出于各种原因，人们非常不愿意支持这 15 条曲线，更不用说“一般”曲线了：
- 所涉及的数学被认为是“难”的（这比 RSA 或普通的 Diffie-Hellman 更难掌握）。
- ...对于二进制字段中的曲线更是如此。
- 虽然可以编写“通用”曲线处理代码，但针对特定曲线的代码通常更易于实现且速度更快。特别是，P-* 曲线工作模素值，其格式使实现更有效（快速模减少）。
- 专利的重复性和长期存在的权利要求，使得椭圆曲线的使用“有风险”。
- ...尤其适用于二进制域中的曲线；
- ...更一般地，对于选择具有某些有利于实现的特性的通用曲线。目前尚不清楚曲线是否可以申请专利（与特殊曲线结构支持的实现技术相反），但不确定性已经起到了强大的劝阻作用。
因此，人们对实现对椭圆曲线的通用支持持谨慎态度，因为它似乎很难，不利于性能，而且是一个合法的雷区。坚持一些更简单的曲线似乎更容易、更快、更安全；这就是发生的事情。NIST（好吧，NSA）将这一趋势正式化为他们的“套件 B ”密码学套件，它要求执行两条曲线：P-256 和 P-384。
在 SSL/TLS 和 X.509 中，可以使用任意曲线。但是，大多数实现不支持任意曲线。OpenSSL 支持所有 15 条 NIST 曲线，但不支持任意曲线。Firefox 仅支持 P-256 和 P-384；我不确定微软的代码（Windows，因此是 Internet Explorer）是否会接受更多（也许 P-521 也是如此）。如果您尝试使用除 P-256 或 P-384 之外的任何其他曲线，那么您将遇到互操作性问题（比尝试使用椭圆曲线所遇到的问题更多）。一些标准编写者认为他们必须“实用”，已经完全承认了这一事实，并且只是禁止使用其他曲线，正如您在RFC 5480中看到的那样。
生成自己的曲线并不难，但比生成自己的 DH 参数要困难得多。它涉及使用Schoof 算法或其变体进行点计数。您将无法在一小时和一百行 Java 代码中拼凑出一个曲线生成器，而生成 DH 参数可以在这些限制下完成。计算成本也更高（您仍然会在一分钟内获得漂亮的曲线，但不会在 100 毫秒内）。简而言之，人们不会经常这样做，或者根本不会这样做。