楕円曲線DSA（だえんきょくせんDSA、Elliptic Curve Digital Signature Algorithm、Elliptic Curve DSA、楕円DSA、ECDSA）は、Digital Signature Algorithm (DSA) について楕円曲線暗号を用いるようにした変種である。

 DSAとの比較 
楕円曲線暗号で一般的に言われるように、ECDSAにおいて必要とされる公開鍵のサイズはセキュリティビット数のおよそ2倍であると考えられている。例えば、80ビットのセキュリティビット数（攻撃者が秘密鍵を取得するために 回の計算を必要とする）を得るために、DSAでは最低でも1024ビットの公開鍵が必要であるが、ECDSAでは160ビットの公開鍵で十分である。一方、署名のサイズはDSAでもECDSAでも同じであり、必要とするビット安全性の4倍のビット長を要する（80ビットのビット安全性を保つためには320ビットの長さの署名が必要）。

 署名生成 
 パラメーター 説明 E 上で定義される楕円曲線 (ワイエルシュトラスの標準形) p E 上の有理点を還元する素数。E は 上の楕円曲線に写される G 上のベースポイント n G の位数（ を満たす）秘密鍵：の範囲からランダムに選択され保持される整数公開鍵： ( 上の点)m送信されるメッセージ
(注1) 、 は の元であり、 の元 および の組 から成る2次元ベクトル値である。これに対して は整数であり、以降ベクトル値に対してスカラー値と呼ぶことにする( は の元でもある)。また、以降、小文字で始まる変数はスカラー値、大文字で始まる変数はベクトル値とする。
(注2)「」はスカラー値とベクトル値の楕円曲線上での掛け算 (scalar multiplication) を意味する。

アリスが署名したメッセージをボブに送る場合を考える。最初に、使用する楕円曲線のパラメータ を決めておく必要がある。

アリスは の範囲からランダムに選択された秘密鍵 と、公開鍵 から成る鍵ペアを生成する。 と の対応は1対1であり、 から を計算することは比較的容易だが、 から を計算することは実質的に不可能(離散対数問題)である。つまり と の対応は一方向性関数になっている。

アリスがメッセージ に署名する場合、以下の計算を行う。

 を計算する。ここで H はSHA-1のような暗号学的ハッシュ関数を指す。
 を、 の最上位側の ビットとする。ここで は位数 のビット長とする。
 の範囲から整数 を任意に選択する。 を「1回秘密鍵」と呼ぶことにする。
 曲線上の点 を計算する。
 を計算する。 となる場合には の選択に戻る。
 を計算する(は有限体におけるの逆元である)。 となる場合には の選択に戻る。
 が に対する署名となる。
(注3) を計算する際に、 から得られる は整数に変換される。 は より「大きい」ことは許されるが、「長い」ことは許されない。
(注4) の 0 以外の任意の元 の における逆元 は、フェルマーの小定理から であるから、 によって計算できる。
(注5) 上記ステップ4と5において計算され、署名として公表される の値から の値を求めることは離散対数問題であり、実質的に不可能である。従って を公表しても の値の秘密は保たれるとしてよい。もし、 の値が外部に漏れた場合は、ステップ6において計算され、 と共に署名として公表される の値から、ステップ6の式によって の値を逆算できることになり、アリスの署名の信頼性は壊滅することになる。
(注6) DSAと同様に、署名ごとに異なる を選択することは極めて重要である。さもないと、ステップ6の式から秘密鍵 を得ることが可能となってしまう。メッセージ および に対して、未知だが同じ から得られた2つの署名 および がある場合、攻撃者は および を計算することが可能であり、 であることから、 が得られる。 であるから、攻撃者は秘密鍵 を得ることができる。このように単一の を用いることは不適切な実装であり、PlayStation 3のソフトウェア署名鍵が漏洩したのはこれが原因であった。

 署名検証 
ボブがアリスの署名を検証するためには、アリスの公開鍵 が必要である。公開鍵 が正当なものであるかの検証は以下のとおりである。

 が でないことを確認する。
 が曲線上にあることを確認する。
 であることを確認する。

メッセージ と署名 の検証は以下のように行われる。

 および がいずれも の範囲にある整数であることを確認する。これを満たさない場合には署名は不正なものである。
 を計算する。ここで H は署名生成に用いられたハッシュ関数と同一のものである。
 を、 の最上位側の ビットとする。
 を計算する。
 および を計算する。
 曲線上の点 を計算する。
 であれば署名は正当なものである。

Straus's algorithm（Shamir's trickとも）を用いることで、2つの楕円曲線上での掛け算の和 を、2つの楕円曲線上での掛け算よりも速く計算することができる。

 署名検証アルゴリズムの説明 
メッセージ に対する署名 が、秘密鍵 の値を知っている者によって正しく生成されたものと仮定する。

 を署名検証のステップ6で得られた点とする。つまり、

公開鍵が と定義されているので

楕円曲線上での掛け算より

署名検証のステップ5から

 を外に出して

は有限体 における の逆元であるから である。これから

署名の作成者は、1時秘密鍵 の値を自分で決めて、署名生成のステップ4とステップ5にって の値を求めるまでのことは可能であるが、秘密鍵 の値を知らない場合は、署名生成のステップ6の の値を正しく決めることはできない。

署名検証のステップ7、つまり が成立するということは、上記の最後の式が成立しているということであり、これは署名の作成者は、 の値を正しく決めていたことをを意味する。このためには署名の作成者は の値を知っている必要があり、最初の仮定「署名の作成者は秘密鍵 の値を知っている」が肯定されることになる。

なお、以上は秘密鍵 の値を知っている者が、正しく署名したメッセージは、正しく検証されるということを示しているが、秘密鍵 の値を知っている者が、本当にアリスであるかは別問題である。例えば前述のように、異なるメッセージに対して、同一の1回秘密鍵 を用いて署名した場合、 の値を解読されて、さらにこれから の値も解読されることになる。

 セキュリティ 
2010年12月、fail0verflowと名乗るグループが、ソニーがPlayStation 3のソフトウェア署名に用いていたECDSA秘密鍵の回復に成功したと発表した。しかし、これは をランダムではなく固定値としていたソニーの不適切な実装によるものであり、アルゴリズム自体の脆弱性ではない。署名生成のセクションで述べたように、 を固定値で用いることは秘密鍵 を計算可能とし、アルゴリズムを破綻させるものである。

2011年3月29日、2人の研究者による論文がに発表された。この論文では、サイドチャネル攻撃の一つであるタイミング攻撃によって、ECDSAを認証に利用し、OpenSSLを用いたサーバのTLS秘密鍵を入手可能であることが示された。この脆弱性はOpenSSL 1.0.0eで修正された。

2013年8月、Java class SecureRandomのいくつかの実装において、 のコリジョンが発生することがあるバグが明らかとなった。前述のように、これにより秘密鍵を得ることが可能であり、Javaを利用しECDSAを認証に用いていたAndroidアプリからBitcoinが盗まれる危険性があった。この問題は独立提出のにあるように、秘密鍵とメッセージハッシュから決定論的に を導くことで回避できる。

2015年1月、Bitcoinのウォレットが完全にオフラインであっても、ECDSAを利用したトランザクションのデジタル署名を通して秘密鍵が漏洩される可能性があることを示す研究論文がarXivにて発表された。この論文では、利用ユーザー側がECDSAおよびビットコインの実装を完全に検証できない限り信頼できないことから、ソースコードの検証からコンパイルといったユーザー側の敷居が高くなるため、プライベートキー漏洩の攻撃を防ぐための実質的な解決策が現段階でないと結論付けている。

このアルゴリズムは楕円曲線をパラメータとして必要とするが、多くの場合NISTによって定められた楕円曲線（P-256、P-384、P-521など）が用いられる。これらの曲線は特定のシード値からSHA-1を基盤としたアルゴリズムを用いて算出されているが、シード値の根拠が不明であること、また同じく固定の楕円曲線を用いたアルゴリズムであるにNSAがバックドアを仕込んだ上でRSAセキュリティ社のセキュリティ製品に採用させたと報道されたことから、疑いの目で見られることがある。

 実装ライブラリ 
ECDSAをサポートしているライブラリは以下の通りである。

 Botan
 
 
 
 
 OpenSSL
 GnuTLS
 wolfCrypt