Curve25519 在 ECDSA 中的使用
I'm currently investigating the use of curve25519 for signing. Original distribution and a C implementation (and a second C implementation).
Bernstein suggests to use ECDSA for this but I could not find any code.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
ECDSA 由 ANSI X9.62 指定。该标准定义了 ECDSA 定义的曲线类型，包括详细的曲线方程、关键表示等。这些与Curve25519不匹配：使Curve25519比相同尺寸的标准曲线更快的部分优化依赖于特殊的曲线方程，该方程没有进入X9.62形式主义。相应地，不可能存在既符合 ANSI X9.62 又使用 Curve25519 的 ECDSA 实现。实际上，据我所知，Curve25519 上没有类似 ECDSA 的算法的实现。
简而言之，你只能靠自己。您可能希望通过遵循 X9.62（有 1998 年的草案，可以从多个地方下载，例如 那里，或者你可以花一百美元从 Techstreet）。但请注意，您正在走出分析密码学的谨慎路径；换句话说，我明确否认对这种 ECDSA 的安全性提供任何形式的保证。
我的建议是坚持使用标准曲线（例如 NIST P-256）。请注意，虽然 Curve25519 比大多数相同大小的曲线更快，但较小的标准曲线会更快，并且为大多数用途提供足够的安全性。例如，NIST P-192 提供“96 位安全性”，有点类似于 1536 位 RSA。此外，标准曲线已经在小型 PC 上提供了每秒数千个签名的性能，我很难想象需要更高性能的场景。
ECDSA is specified by ANSI X9.62. That standard defines the kind of curves on which ECDSA is defined, including details curve equations, key representations and so on. These do not match Curve25519: part of the optimizations which make Curve25519 faster than standard curves of the same size rely on the special curve equation, which does not enter in X9.62 formalism. Correspondingly, there cannot be any implementation of ECDSA which both conforms to ANSI X9.62, and uses Curve25519. In practice, I know of no implementation of an ECDSA-like algorithm on Curve25519.
To be brief, you are on your own. You may want to implement ECDSA over the Curve25519 implementation by following X9.62 (there a draft from 1998 which can be downloaded from several places, e.g. there, or you can spend a hundred bucks and get the genuine 2005 version from Techstreet). But be warned that you are walking outside of the carefully trodden paths of analyzed cryptography; in other words I explicitly deny any kind of guarantee on how secure that kind-of-ECDSA would be.
My advice would be to stick to standard curves (such as NIST P-256). Note that while Curve25519 is faster than most curves of the same size, smaller standard curves will be faster, and yet provide adequate security for most purposes. NIST P-192, for instance, provides "96-bit security", somewhat similar to 1536-bit RSA. Also, standard curves already provide performance on the order of several thousands signature per second on a small PC, and I have trouble imagining a scenario where more performance is needed.
要使用 Curve25519 来实现此目的，您必须实现许多据我所知目前尚未在该曲线的任何地方实现的函数，这意味着要深入了解椭圆曲线密码学的数学知识。原因是现有函数丢弃了点的“y”坐标，而仅使用“x”坐标。如果没有“y”坐标，点 P 和 -P 看起来是一样的。这对于 Curve25519 所设计的 ECDH 来说很好，因为 |x(yG)| = |x(-yG)|。但对于 ECDSA，您需要计算 aG + bP 和 |aG + bP|一般不等于 |aG - bP|。我研究了扩展 curve25519-donna 以支持此类计算所涉及的内容；这是可行的，但绝非微不足道。
由于您最需要的是快速验证，因此我推荐 Bernstein 的 Rabin-Williams 方案。
To use Curve25519 for this, you'd have to implement a lot of functions that AFAIK aren't currently implemented anywhere for this curve, which would mean getting very substantially into the mathematics of elliptic curve cryptography. The reason is that the existing functions throw away the "y" coordinate of the point and work only with the "x" coordinate. Without the "y" coordinate, the points P and -P look the same. That's fine for ECDH which Curve25519 is designed for, because |x(yG)| = |x(-yG)|. But for ECDSA you need to calculate aG + bP, and |aG + bP| does not in general equal |aG - bP|. I've looked into what would be involved in extending curve25519-donna to support such calculations; it's doable, but far from trivial.
Since what you need most of all is fast verification, I recommend Bernstein's Rabin-Williams scheme.
我最近分享了我不久前开发的 curve25519 库。它托管在 https://github.com/msotoodeh 并提供更多功能、更高的安全性以及更高的性能比我测试过的任何其他可移植 C 库都要好。它在 64 位平台上比 curve25519-donna 的性能高出近 2 倍，在 32 位目标上高出近 4 倍。
I recently shared the curve25519 library that I developed awhile back. It is hosted at https://github.com/msotoodeh and provides more functionality, higher security as well as higher performance than any other portable-C library I have tested with. It outperforms curve25519-donna by a factor of almost 2 on 64-bit platforms and a factor of almost 4 on 32-bit targets.
今天，在这个问题被提出多年之后，正确的答案是签名方案 Ed25519。
Today, many years after this question was asked, the correct answer is the signature scheme Ed25519.