私は現在、署名のためのcurve25519の使用を調査しています。元の配布とC実装(および2番目のC実装)。
BernsteinはこれにECDSAを使用することを提案していますが、コードが見つかりませんでした。
ECDSA は ANSI X9.62 で指定されています。この規格は、ECDSA が定義されている曲線の種類を定義しており、詳細な曲線方程式、主要な表現などを含んでいます。これらは Curve25519 と一致しません: Curve25519 を同じサイズの標準曲線よりも高速にする最適化の一部は、X9.62 形式には含まれない特別な曲線方程式に依存しています。それに対応して、ANSI X9.62 に準拠し、Curve25519 を使用する ECDSA の実装はあり得ません。実際には、Curve25519 に ECDSA のようなアルゴリズムが実装されていないことを私は知っています。
簡単に言えば、あなたはあなた自身です。X9.62 に従って、Curve25519 実装に ECDSA を実装することをお勧めします (1998 年のドラフトがあり、いくつかの場所からダウンロードできます。ただし、分析された暗号化の慎重に踏まれた道の外を歩いていることに注意してください。言い換えれば、私は、その種の ECDSA がどれほど安全であるかについて、いかなる種類の保証も明示的に否定します。
私のアドバイスは、標準曲線 (NIST P-256 など) に固執することです。Curve25519 は同じサイズのほとんどの曲線よりも高速ですが、小さい標準曲線は高速であり、ほとんどの目的に対して十分なセキュリティを提供することに注意してください。たとえば、NIST P-192 は、1536 ビット RSA にいくらか似た「96 ビット セキュリティ」を提供します。また、標準曲線は、小型 PC で 1 秒あたり数千署名のオーダーのパフォーマンスをすでに提供しており、さらにパフォーマンスが必要なシナリオを想像するのに苦労しています。
これにCurve25519を使用するには、この曲線のどこにもAFAIKが現在実装されていない多くの関数を実装する必要があります。これは、楕円曲線暗号の数学に非常に深く入り込むことを意味します. その理由は、既存の関数が点の "y" 座標を破棄し、"x" 座標でのみ機能するためです。「y」座標がなければ、点 P と -P は同じに見えます。|x(yG)| であるため、Curve25519 が設計されている ECDH では問題ありません。= |x(-yG)|。しかし ECDSA の場合、aG + bP と |aG + bP| を計算する必要があります。は一般に |aG - bP| と等しくありません。そのような計算をサポートするためにcurve25519-donnaを拡張することに何が関係するかを調べました。それは実行可能ですが、些細なことではありません。
何よりも必要なのは迅速な検証であるため、Bernstein の Rabin-Williams スキームをお勧めします。
この質問が出されてから何年も経った今日、正しい答えは署名方式Ed25519です。