CRYPTREC EX-3102-2021

ディジタル署名アルゴリズム
EdDSA の実装性能調査

株式会社インフォーズ
2021 年 12 月

エグゼクティブサマリー
本報告書はディジタル署名 Edwards-curve Digital Signature Algorithm（EdDSA）の実装性能に関する評価結果を報告するものである．
EdDSA とは，2011 年 9 月に Daniel J. Bernstein らによって“High-speed high-security signatures” [1]で発表され，Internet Research Task Force（IRTF）の Request for Comments（RFC）8032 [2]で規定されるディジタル署名のことであり，有限体上の twisted Edwards 曲線 [3] [4]といわれる楕円曲線上の Schnorr 署名 [5] [6]の署名内部乱数（ノンス）を署名者の秘密情報と署名されるメッセージのハッシュ値に置き換えた確定的（deterministic）版の Schnorr 署名である．EdDSA で推奨される
twisted Edwards 曲線は IRTF の RFC7748 [7]で規定されるものであり edwards25519，
edwards448 と記述される．
以下，評価結果の概要を述べる．
•

EdDSA の技術的な特徴として以下を確認できた．
➢ EdDSA は ECDSA と同様に射影座標系を使用可能であるため，有限体上の乗法逆元の演算を用いずに演算可能であることから，高速な実装が可能である．
➢ EdDSA で推奨される twisted-Edwards 曲線は無限遠点を例外的に扱うための分岐が不要なため，ECDSA で使われる Weierstrass 形式の楕円曲線と比較して実装しやすい．
➢ EdDSA で推奨される Edwards 楕円曲線は，異なる点の加算と同一の点の加算(2 倍算)を同じ処理で計算できるため，実装するアルゴリズムが 1
つでよく，点が異なるかどうかの条件分岐を考慮する必要がないた
め，Weierstrass 形式の楕円曲線と比較して Side Channel Attack（SCA）対策に有利である．

•

EdDSA の標準化での採用状況としては，RFC8032 [2]として標準化され，Draft
版を含め参照する標準も増えつつあることが分かった．Open Source Software（OSS）での採用状況としては，少なくとも 20 件の OSS の暗号ライブラリが採用していることが分かった．ただし，224 ビットセキュリティの EdDSA である
Ed448 は 128 ビットセキュリティの EdDSA である Ed25519 よりも採用数は少な
かった．今後，EdDSA の実装の品質や高速化技法が洗練され，安全性の高い
Ed448 も性能が高まると採用が進むことが期待できる．

•

公開されている第三者の測定結果および本調査での実装評価として，4 つの C
言語実装および 2 つの Java 言語実装の OSS に対して，Windows，Linux，Macの環境でそれぞれでの性能測定を実施した.その結果は以下のとおりである.
➢ Ed255519

•

•

•
➢

鍵ペア生成
◼ ほぼ全ての環境において ECDSA P-256 より高スループットであった．
署名生成◼ 半数以上の環境で ECDSA P-256 より高スループットであり，それ以外の環境において半分以下のスループットとなることはなかった．
署名検証◼ ほぼ全ての ECDSA P-256 より高スループットであった．

Ed448• 鍵ペア生成◼ ほぼ全ての環境で ECDSA P-384 より高スループットであり，全環境で ECDSA P-521 より高スループットであった．
• 署名生成◼ ほぼ全ての環境で ECDSA P-384 より高スループットであり，全環境で ECDSA P-521 より高スループットであった．
• 署名検証◼ ほぼ全ての環境で ECDSA P-384 より高スループットであり，全環境で ECDSA P-521 より高スループットであった.

以上から，EdDSA は，方式そのものに安全性担保，高速化，実装がしやすい特性があると評価でき，実際に OSS として実装された暗号ライブラリの性能は，同程度の安全性の ECDSA や高い安全性の ECDSA と比べても遜色のないものであった．実装された
OSS の品質，高速化技法は洗練されているとは言い切れない部分もあるが，歴史のある ECDSA と比べても性能で劣ることはないと考えられる．

目次
1. はじめに ............................................................... 1
2. 数学的記法 ............................................................. 3
3. EdDSA の技術的解説 ...................................................... 4
3.1. EdDSA の処理内容の解説 .............................................. 4
3.1.1. データ変換 ...................................................... 5
3.1.2. Ed25519，Ed25519ctx，Ed25519ph 共通パラメータ ................... 7
3.1.3. Ed25519，Ed25519ctx，Ed25519ph 共通処理 ......................... 7
3.1.4. Ed25519 ......................................................... 9
3.1.5. Ed25519ctx ..................................................... 10
3.1.6. Ed25519ph ...................................................... 11
3.1.7. Ed448，Ed448ph 共通パラメータ .................................. 12
3.1.8. Ed448，Ed448ph 共通処理 ........................................ 12
3.1.9. Ed448 .......................................................... 14
3.1.10. Ed448ph ........................................................ 15
3.2. 実装の解説 ........................................................ 16
3.2.1. Edwards 曲線の特徴 ............................................. 16
3.2.2. EdDSA の特徴 ................................................... 17
3.2.3. RFC8032 に記載されている注意点 ................................. 20
3.2.4. SCA 対策 ....................................................... 21
3.2.5. 長いメッセージに対する配慮 ..................................... 22
3.2.6. パラメータ𝑛の選択.............................................. 223.3. Ed25519 実装の解説 ................................................. 23
3.4. Ed448 実装の解説 ................................................... 25
4. EdDSA の標準化動向や OSS に関する採用状況など ........................... 28
4.1. EdDSA に関する標準化動向調査 ....................................... 28
4.2. 標準仕様における EdDSA に関する採用状況 ............................ 30
4.3. EdDSA に関する OSS 採用状況 ......................................... 36
4.4. EdDSA 実装の脆弱性に関する状況 ..................................... 40
5. 現在の電子政府推奨暗号リストに含まれる同技術分類の方式（ECDSA）との性能比
較調査 .................................................................... 43
5.1. 性能比較調査について .............................................. 43
5.2. ECDSA および EdDSA が実装されている OSS の選定 ....................... 43
5.3. 第三者による性能比較 .............................................. 44
5.3.1. eBATS による測定結果 ........................................... 44
5.3.2. 論文“Is there a case to prefer Ed25519 over ECDSA P-256 for
DNSSEC?”での測定結果 ................................................. 55
5.3.3. 論文“Size, Speed, and Security: An Ed25519 Case Study”での測定結果............................................................... 57i

5.4. ECDSA および EdDSA に関する性能評価 ................................. 58
5.4.1. 性能評価対象 ................................................... 58
5.4.2. 性能測定方法 ................................................... 58
5.4.3. 性能測定結果と評価 ............................................. 94
6. EdDSA に関する実装評価まとめ .......................................... 106
7. 参考文献 ............................................................. 108ii

1. はじめにディジタル署名方式である Edwards-curve Digital Signature Algorithm(EdDSA)とは，2011 年に Daniel J. Bernstein らによって “High-speed high-security signatures”として発表され [1]，Internet Research Task Force（IRTF）の Request forComments（RFC）8032“Edwards-Curve Digital Signature Algorithm (EdDSA)” [2]で標準化されたアルゴリズムである．
EdDSA については，現在，CRYPTREC において 2020 年度 CRYPTREC 外部評価報告として，「ディジタル署名 EdDSA の構成の安全性に関する調査および評価」 [8]，「ディジタル署名 EdDSA で使われている曲線の安全性に関する調査及び評価」 [9]および「CRYPTREC Review of EdDSA」 [10]として理論的な側面に関する評価結果が公開されている．
[8]は，EdDSA の構成の安全性について「証明可能安全性という枠組みでは不十分であったり十分なビット安全性が保証されなかったりするが，Schnorr 署名という成熟した方式をもとにノンスの生成で既存の攻撃を注意深く回避する配慮がされており現実的には安全である」と評価している．
[9]は，EdDSA に対する現時点で最良の攻撃は ρ 法 [11]としており，EdDSA で使われている曲線の安全性について，Curve25519 は「2125.8257 回の点の加算が必要」，
Curve448 は「2222.8257 回の点の加算が必要」であり，「Curve25519 における ECDLP を攻撃するには，少なくとも2125.8257 回の楕円加算が必要であり，ほぼ 128 ビットのセ
キュリティレベルを持つと結論付けられる」と評価している．
[10]は，EdDSA について「I am confident that EdDSA using Curve25519 is agood signature scheme for use up to 2030.」として評価している．
本調査報告書では，理論的な面での評価が行われている EdDSA に対して，実社会で利用するために必要とされる標準化動向や手軽に利用するための環境としての OSS に関する状況を把握するための実装性能評価を行いその結果を報告する．
本報告書で対象となっている EdDSA は，IETF において RFC8032“Edwards-Curve
Digital Signature Algorithm (EdDSA)” [2]として 2021 年 1 月に RFC として発行されたディジタル署名方式である．これは，twisted Edwards 曲線 [7]と言われる有限体上の楕円曲線表現を用いた Schnorr 署名 [5]の署名内部乱数（ノンス）を署名者の秘密情報と署名される平文のハッシュ値に置き換えた確定的（Deterministic）な
Schnorr 署名である．また，EdDSA で使用される（twisted）Edwards 曲線について
は，RFC8032 に先駆けて 2015 年 10 月に発行された RFC7748“Elliptic Curves for
Security” [7]において，edwards25519 および edwards448 として規定されている1．

1[6]は，Montgomery 型曲線“curve25519”とその双有理的同値な twisted Edwards 曲線“ed25519”，Montgomery 型曲線“curve448”とその双有理的同値な Edwards 曲線“ed448”を定義している．

1

2019 年 11 月に National Institute of Standards and Technology（NIST）は米国の連邦情報処理標準におけるディジタル署名の改定版 Federal Information Processing Standards（FIPS）Pub 186-5 (Draft) Digital Signature Standard (DSS)[12]で EdDSA を追加した．また，EdDSA は RFC8446 で TLS1.3 に採用された．
現在広く利用されている ECDSA に対して，今後，EdDSA の利用が進むと予想される状況の中，CRYPTOREC では上記の外部評価を受けて，“暗号技術検討会 2020 年度報告書”において，Curve25519 の場合はほぼ 128 ビットセキュリティ，Curve448 の場合はほぼ 224 ビットセキュリティの安全性を持ち，現実的な脅威に結びつくような脆弱性，安全性に問題を与える点はないと判断し，CRYPTREC 暗号リストへの追加を視野に入れた検討として，実装性能評価を行うことを報告している．
本報告書の構成について以下のとおりである．2 章で必要な記法の準備を行い，3 章
で EdDSA の仕様および実装について記述する．4 章で EdDSA が標準化やオープンソー
スソフトウェアでどのように採用されているかを記述し，5 章で EdDSA と ECDSA の実測した性能を比較した結果を記述し，6 章で 5 章までの調査結果を踏まえて，EdDSA の実装性能についてまとめを記述する．
なお，本報告書は，2021 年 12 月時点での情報に基づき記載している．

2

2. 数学的記法
本報告書で用いる数学的記法を準備する．
オクテット列
𝑝
GF(𝑝)
𝑥𝑦
𝐵
[𝑛]𝑋
ℎ[𝑖]
ℎ𝑖
𝑎 || 𝑏
𝑎≤𝑏
𝑎≥𝑏
𝑖+𝑗
𝑖∗𝑗
𝑖−𝑗
𝑖/𝑗
𝑖×𝑗

0 から 255 までの数値の並び．
基礎となる体を定義する素数．
𝑝個の元の有限体．
𝑥の𝑦乗．
楕円曲線上の点による群または部分群の生成元．
𝑋を𝑛回加算したもの．
オクテット列ℎの𝑖番目のオクテット．
ℎの𝑖番目のビット．
（ビット）列𝑎の後ろに（ビット）列𝑏を連結したもの．
𝑎は𝑏以下．
𝑎は𝑏以上．
𝑖と𝑗の和．
𝑖と𝑗の積．
𝑖から𝑗を引いた差．
𝑖を𝑗で割る除算．
𝑖と𝑗の直積．

(𝑢, 𝑣)SHAKE256(𝑥, 𝑦)
SHA512(𝑥)OCTET(𝑥)OLEN(𝑥)𝑥座標が𝑢，𝑦座標が𝑣であるような楕円曲線上の点．
入力𝑥に対する SHAKE256 [13]の出力の先頭𝑦オクテット．
入力𝑥に対する SHA-512 [14]の出力（64 オクテット）．
値𝑥のオクテット列．
オクテット列𝑥のオクテット数．

3

3. EdDSA の技術的解説
RFC8032 で定められた EdDSA が次世代の署名アルゴリズムとして注目される理由として，安全性だけでなく性能も考慮されたアルゴリズムであることが挙げられる．
本章ではアルゴリズムの持つ性能面の優位性を紐解くため，EdDSA の処理内容の解説，実装面での特徴を解説する．

3.1. EdDSA の処理内容の解説
RFC8032 [2]および RFC7748 [7]をもとに整理した処理内容の解説を行う．なお，解説を行う上で説明のために RFC8032 [2]および [7]と記述が異なる部分が存在している．
RFC8032 [2]では汎用的な EdDSA だけでなく，以下のような選択肢を持つアルゴリズ
ムも記載されている．以下に EdDSA における選択可能な項目を示す.
• Edward 曲線の種類➢ RFC7748 [7]で規定された edwards25519/edwards448 のどちらの曲線• ハッシュ値の状態➢ 署名生成，署名検証の処理の初期段階でメッセージのハッシュ値を保持するかどうか• コンテキストの状態➢ 署名者と検証者があらかじめ合意するバイト列の状態
RFC8032 [2]では選択肢を組み合わせた以下のアルゴリズムが記載されている．
• RFC7748 [7]の edwards25519 のための EdDSA（128 ビットセキュリティ2）➢ ハッシュ値を保持しない
 Ed25519:0 バイトのコンテキストを入力する
 Ed25519ctx:1 バイト以上のコンテキストを入力する➢ ハッシュ値を保持する
 Ed25519ph:0 バイト以上のコンテキストを入力する• RFC7748 [7]の edwards448 のための EdDSA（224 ビットセキュリティ）➢ ハッシュ値を保持しない
 Ed448:0 バイト以上のコンテキストを入力する➢ ハッシュ値を保持する
 Ed448ph:0 バイト以上のコンテキストを入力する
以下では，これらの名前の付けられた 5 つのアルゴリズムについて解説する．

2[8]によると RFC8032 [1]に記載された通りではないと評価されているが，本書では同程度の強度のアルゴリズムと比較する目安として，RFC8032 [1]に記載された通りの暗号強度を記載している．

4

3.1.1.

データ変換

5 つのアルゴリズム共通で使用するデータとデータ間の変換について解説する．
[2]では，下記の種類のデータを扱う．

• オクテット列• 整数• 元（GF(𝑝)の要素）• 点
EdDSA で必要な変換は“オクテットと整数”，“オクテット列と元”および“オクテット列と点”である．オクテット列への変換をエンコード，オクテット列からの変換をデコードと呼ぶ．
以下で𝑏は 5 つのアルゴリズムで定義されるパラメータである．具体的には，
Ed25519，Ed25519ctx および Ed25519ph の場合は𝑏 = 256であり，Ed448，Ed448ph の場
合は𝑏 = 456である．

① オクテット
8 ビットのビット列
𝑏0 𝑏1 𝑏2 𝑏3 𝑏4 𝑏5 𝑏6 𝑏7
を 1 つのオクテットとする．𝑏0 を最下位ビット，𝑏7 を最上位ビットと呼ぶ．
例えば，値が 128 のオクテットに対応するビット列は最下位ビットから 7 ビットが0 で最上位ビットが 1 の 00000001 である．

② 整数
整数のエンコードをENCI(𝑠)と表記する．
𝑠は変換元の整数である．変換は，整数を 256 進数表現したときの各桁をオクテット𝑏とみなすことに基づき，リトルエンディアンの並び順で8オクテットに格納する処理である．
例えば，整数𝑠が以下のように 256 進数表現できる場合
𝑠 = 𝑠2 ∗ 2562 + 𝑠1 ∗ 256 + 𝑠0
ENCI(𝑠)は次のオクテット列を表す．
𝑠0 𝑠1 𝑠2 0 … 0
⏟
𝑏
オクテット
8

整数のデコードをDECI(𝑡)と表記する．
𝑏𝑡は変換元の8オクテットのオクテット列である．変換は，前項のENCI(𝑠)の逆変換であり，𝑡の各オクテットを 256 進数表現の各桁とみなすことに基づく．

5

𝑏
8

例えば オクテットのオクテット列𝑡が以下の場合
𝑡 = 𝑡⏟0 𝑡1 𝑡2 0 … 0
𝑏
オクテット
8

DECI(𝑡)は次の整数を表す．
0 ∗ 2563 + 𝑡2 ∗ 2562 + 𝑡1 ∗ 256 + 𝑡0

③ 元
元のエンコードをENCF(𝑥)と表記する．
𝑥は変換元の元である．変換は，𝑥を{0,1, … , 𝑝 − 1}における範囲の整数としたときのENCI(𝑥)である．ENCF(𝑥)のビット列は最上位ビットが必ず 0 になる．
元のデコードをDECF(𝑡)と表記する．
𝑏𝑡は変換元の8オクテットのオクテット列である．変換は，前項のENCF(𝑥)の逆変換であり，DECI(𝑡)（{0,1, … , 𝑝 − 1}でなければならない）をGF(𝑝)の元とみなすことである．

④ 点
ENCE(𝐴):
点のエンコードをENCE(𝐴)と表記する．
𝐴は変換元の点である．変換は，𝐴の𝑦座標をENCFでオクテット列に変換し，その最終オクテットの最上位ビットに𝐴における𝑥座標の符号（正または 0：0，負：1）を格納する．
ENCF(𝐴の𝑥座標)のビット列がENCF (−(𝐴の𝑥座標))のビット列より辞書順に大きい
場合，𝐴の𝑥座標の符号を負と定義する．ここで「辞書順に」とは，先頭ビット（最下位ビット）から順に比較していくことを意味している．
𝐴の𝑥座標と，−(𝐴の𝑥座標) = 𝑝 − (𝐴の𝑥座標)は，𝑝が奇数であるため必ず偶奇が異なる．つまり，ENCF(𝐴の𝑥座標)の最下位ビットとENCF (−(𝐴の𝑥座標))の最下位ビッ
トは必ず異なり，ENCF(𝐴の𝑥座標)の最下位ビットが 1 であることで辞書順に大きい，
すなわち負と分かる．
したがって，点のエンコード処理は以下となる．
1. 𝑡 = ENCF(𝐴の𝑦座標)𝑏2. 𝑡 [8 − 1] = ENCF(𝐴の𝑥座標)07

3. 𝑡を出力する.
DECE(𝑡):元のデコードをDECF(𝑡)と表記する．
𝑏𝑡は変換元の8オクテットのオクテット列である．

6

変換は以下の手順で行う．
𝑏8

1. 𝑥0 = 𝑡 [ − 1]2.

7𝑏𝑡 [8 − 1] = 0
7

3. 𝑦 = DECF(𝑡)4. 𝑦 ≥ 𝑝ならばデコード失敗とする．
5. Ed25519，Ed25519ctx，Ed25519ph の場合
(ア)
(イ)

𝑝−5

𝑢 = 𝑦 2 − 1，𝑣 = 𝑑𝑦 2 + 1として𝑥 = 𝑢𝑣 3 (𝑢𝑣 7 ) 8 mod 𝑝𝑣𝑥 2 ≠ ±𝑢 mod 𝑝ならばデコード失敗とする．
𝑝−1(ウ)𝑣𝑥 2 = −𝑢 mod 𝑝ならば，𝑥 = 2 4 𝑥
6. Ed448，Ed448ph の場合
𝑝−3(ア)
𝑢 = 𝑦 2 − 1，𝑣 = 𝑑𝑦 2 − 1として𝑥 = 𝑢3 𝑣(𝑢5 𝑣 3 ) 4 mod 𝑝(イ)𝑣𝑥 2 ≠ 𝑢 mod 𝑝ならばデコード失敗とする．
7. 𝑥 = 0かつ𝑥0 = 1ならばデコード失敗とする．
8. 𝑥0 が𝑥 mod 2と異なるならば𝑥 = 𝑝 − 𝑥
9. 点(𝑥, 𝑦)を出力する.

3.1.2.

Ed25519，Ed25519ctx，Ed25519ph 共通パラメータ

Ed25519，Ed25519ctx，Ed25519ph では以下の共通パラメータを使用する．
① 𝑝 = 2255 − 19（edwards25519 [7]の𝑝）② 𝑏 = 256③ 𝑐 = 3（edwards25519 [7]の補因子の 2 を底とする対数）④ 𝑛 = 254
121665⑤ 𝑑 = − 121666 = 37095705934669439343138083508754565189542113879
843219016388785533085940283555（edwards25519 [7]の𝑑）⑥ 𝑎 = −1
⑦ 𝐵 = (151122213495354007725011514095885315114540126930418572
06046113283949847762202,46316835694926478169428394003475163
141307993866256225615783033603165251855960960)（edwards25519 [7]の(𝑋(𝑃), 𝑌(𝑃))⑧ 𝐿 = 2252 + 27742317777372353535851937790883648493（edwards25519 [7]の位数）

3.1.3.

Ed25519，Ed25519ctx，Ed25519ph 共通処理

以下の処理は Ed25519，Ed25519ctx，Ed25519ph で共通である．

7

① 点の加算，2 倍算（同一の点の加算），無限遠点との加算
楕円点の加算，2 倍算（同一の点の加算），無限遠点との加算は以下の 1 つの式で計算できる．
𝑥1 𝑦2 + 𝑥2 𝑦1
𝑦1 𝑦2 + 𝑥1 𝑥2
𝑥3 =, 𝑦3 =
1 + 𝑑𝑥1 𝑥2 𝑦1 𝑦2
1 − 𝑑𝑥1 𝑥2 𝑦1 𝑦2
これを RFC8032 [2]で推奨される拡張射影座標系（extended twisted Edwards coordinates）（3.2.1 参照）で計算するアルゴリズムは以下のようになる．
入力：加算する点𝑃1 = (𝑋1 , 𝑌1 , 𝑍1 , 𝑇1 )，点𝑃2 = (𝑋2 , 𝑌2 , 𝑍2 , 𝑇2 )出力：加算結果の点𝑃3 = 𝑃1 + 𝑃2 = (𝑋3 , 𝑌3 , 𝑍3 , 𝑇3 )1. 𝐴 = (𝑌1 − 𝑋1 )(𝑌2 − 𝑋2 )2. 𝐵 = (𝑌1 + 𝑋1 )(𝑌2 + 𝑋2 )3. 𝐶 = 𝑇1 ⋅ 2𝑑 ⋅ 𝑇2
4. 𝐷 = 𝑍1 ⋅ 2 ⋅ 𝑍2
5. 𝐸 = 𝐵 − 𝐴
6. 𝐹 = 𝐷 − 𝐶
7. 𝐺 = 𝐷 + 𝐶
8. 𝐻 = 𝐵 + 𝐴
9. 𝑋3 = 𝐸 ⋅ 𝐹
10. 𝑌3 = 𝐺 ⋅ 𝐻
11. 𝑇3 = 𝐸 ⋅ 𝐻
12. 𝑍3 = 𝐹 ⋅ 𝐺② 2 倍算の高速化
楕円点の 2 倍算は①で計算できるが，入力が同一の点かどうか条件分岐してもよい
場合は高速なアルゴリズムを使うこともできる．拡張射影座標系（3.2.1 参照）で計算するアルゴリズムは以下のようになる．
入力：2 倍算する点𝑃1 = (𝑋1 , 𝑌1 , 𝑍1 , 𝑇1 )
出力：2 倍算結果の点𝑃3 = 𝑃1 + 𝑃1 = (𝑋3 , 𝑌3 , 𝑍3 , 𝑇3 )1. 𝐴 = 𝑋12
2. 𝐵 = 𝑌12
3. 𝐶 = 2𝑍12
4. 𝐻 = 𝐴 + 𝐵
5. 𝐸 = 𝐻 − (𝑋1 + 𝑌1 )2
6. 𝐺 = 𝐴 − 𝐵
7. 𝐹 = 𝐶 + 𝐺
8. 𝑋3 = 𝐸 ⋅ 𝐹
9. 𝑌3 = 𝐺 ⋅ 𝐻

8

10. 𝑇3 = 𝐸 ⋅ 𝐻
11. 𝑍3 = 𝐹 ⋅ 𝐺③ dom2(𝑥, 𝑦)
バイト列"SigEd25519 no Ed25519 collisions"||OCTET(𝑥)||OCTET(OLEN(𝑦))||𝑦．
𝑥は 0～255 の値．
𝑦は最小で 1 バイト，最大で 255 バイトのデータ列．
"SigEd25519 no Ed25519 collisions"は ASCII 文字列（32 バイト）．

④ 鍵生成
入力：なし
出力：秘密鍵𝑘，公開鍵𝐴
1. 𝑘 =暗号的に安全なランダムデータの 32 オクテット
2. ℎ = SHA512(𝑘)（64 オクテット）
3. ℎ[0]0 = 0, ℎ[0]1 = 0, ℎ[0]2 = 0, ℎ[31]7 = 0, ℎ[31]6 = 1
4. 𝑠 = DECI(ℎ) mod 𝐿
5. 𝐴 = ENCE([𝑠]𝐵)（32 オクテット）
秘密のスカラー値𝑠は 8 の倍数で，正確に 255 ビットとなる．

3.1.4.

Ed25519

Ed25519 は，楕円曲線として Edwards25519 を選択し，設定可能な項目としてコンテキストを入力せず，ハッシュ値を保持しない EdDSA のことである．

① 署名生成入力：秘密鍵𝑘（32 オクテット），メッセージ𝑀（任意のサイズのオクテット列）
出力：署名𝜎1. ℎ = SHA512(𝑘)2. ℎ[0]0 = ℎ[0]1 = ℎ[0]2 = ℎ[31]7 = 0，ℎ[31]6 = 1
3. 𝑠 = DECI(ℎ[0]|| … ||ℎ[31])4. 𝐴 = ENCE([𝑠]𝐵)（32 オクテット）
5. 𝑟 = DECI(SHA512(ℎ[32]|| … ||ℎ[63]||𝑀)) mod 𝐿
6. 𝑅 = ENCE([𝑟]𝐵)（32 オクテット）
7. 𝑘 = DECI(SHA512(𝑅||𝐴||𝑀)) mod 𝐿
8. 𝑆 = (𝑟 + 𝑘 ∗ 𝑠) mod 𝐿
9. 𝜎 = 𝑅||ENCO(𝑆)（64 オクテット）
秘密のスカラー値𝑠は 8 の倍数で，正確に 255 ビットとなる．

9

② 署名検証
入力：署名𝜎（64 オクテット），公開鍵𝐴（32 オクテット），メッセージ𝑀（任意のサイズのオクテット列）
出力：署名検証の結果（有効または無効）
1. 𝑅 = DECE(𝜎[0]|| … ||𝜎[31])2. 𝑆 = DECI(𝜎[32]|| … ||𝜎[63])3. 𝐴′ = DECE(𝐴)4. 1.～3.でデコードに失敗した場合（0 ≤ 𝑆 < 𝐿の範囲外であることを含む），無効を出力して終了．
5. 𝑘 = DECI(SHA512(𝑅||𝐴||𝑀)) mod 𝐿
6. [8][𝑆]𝐵 = [8]𝑅 + [8][𝑘]𝐴′ が成り立たない場合は無効を出力し，成り立つ
場合は有効を出力する．

3.1.5.

Ed25519ctx

1 バイト以上のコンテキストを入力し，ハッシュ値を保持しない，Edwards25519 を使った EdDSA である．

① 署名生成入力：秘密鍵𝑘（32 オクテット），メッセージ𝑀（任意のサイズのオクテット列），最小 1 オクテット，最大 255 オクテットのコンテキスト𝐶，フラグ𝐹 = 0（既定値）
出力：署名𝜎1. ℎ = SHA512(𝑘)2. ℎ[0]0 = ℎ[0]1 = ℎ[0]2 = ℎ[31]7 = 0，ℎ[31]6 = 1
3. 𝑠 = DECI(ℎ[0]|| … ||ℎ[31])4. 𝐴 = ENCE([𝑠]𝐵)（32 オクテット）
5. 𝑟 = DECI(SHA512(dom2(𝐹, 𝐶)||ℎ[32]||. . . ||ℎ[63]||𝑀)) mod 𝐿
6. 𝑅 = ENCE([𝑟]𝐵)（32 オクテット）
7. 𝑘 = DECI(SHA512(dom2(𝐹, 𝐶)||𝑅||𝐴||𝑀)) mod 𝐿
8. 𝑆 = (𝑟 + 𝑘 ∗ 𝑠) mod 𝐿
9. 𝜎 = 𝑅||ENCO(𝑆)（64 オクテット）
秘密のスカラー値𝑠は 8 の倍数で，正確に 255 ビットとなる．

② 署名検証
入力：署名𝜎（64 オクテット），公開鍵𝐴（32 オクテット），メッセージ𝑀（任意のサイズのオクテット列），最小 1 オクテット，最大 255 オクテットのコンテキスト𝐶，
フラグ𝐹 = 0（既定値）

10

出力：署名検証の結果（有効または無効）
1. 𝑅 = DECE(𝜎[0]|| … ||𝜎[31])2. 𝑆 = DECI(𝜎[32]|| … ||𝜎[63])3. 𝐴′ = DECE(𝐴)4. 1.～3.でデコードに失敗した場合（0 ≤ 𝑆 < 𝐿の範囲外であることを含む），無効を出力して終了．
5. 𝑘 = DECI(SHA512(dom2(𝐹, 𝐶)||𝑅||𝐴||𝑀)) mod 𝐿
6. [8][𝑆]𝐵 = [8]𝑅 + [8][𝑘]𝐴′ が成り立たない場合は無効を出力し，成り立つ
場合は有効を出力する．

3.1.6.

Ed25519ph

0 バイト以上のコンテキストを入力し，ハッシュ値を保持する，Edwards25519 を使った EdDSA である．

① 署名生成入力：秘密鍵𝑘（32 オクテット），メッセージ𝑀（任意のサイズのオクテット列），最小 0 オクテット，最大 255 オクテットのコンテキスト𝐶，フラグ𝐹 = 1
出力：署名𝜎1. ℎ = SHA512(𝑘)2. ℎ[0]0 = ℎ[0]1 = ℎ[0]2 = ℎ[31]7 = 0，ℎ[31]6 = 1
3. 𝑠 = DECI(ℎ[0]|| … ||ℎ[31])4. 𝐴 = ENCE([𝑠]𝐵)（32 オクテット）
5. 𝑟 = DECI (SHA512(dom2(𝐹, 𝐶)||ℎ[32]||. . . ||ℎ[63]||SHA512(𝑀))) mod 𝐿
6. 𝑅 = ENCE([𝑟]𝐵)（32 オクテット）
7. 𝑘 = DECI (SHA512(dom2(𝐹, 𝐶)||𝑅||𝐴||SHA512(𝑀))) mod 𝐿
8. 𝑆 = (𝑟 + 𝑘 ∗ 𝑠) mod 𝐿
9. 𝜎 = 𝑅||ENCO(𝑆)（64 オクテット）
秘密のスカラー値𝑠は 8 の倍数で，正確に 255 ビットとなる．

② 署名検証
入力：署名𝜎（64 オクテット），公開鍵𝐴（32 オクテット），メッセージ𝑀（任意のサイズのオクテット列），最小 0 オクテット，最大 255 オクテットのコンテキスト𝐶，
フラグ𝐹 = 1
出力：署名検証の結果（有効または無効）
1. 𝑅 = DECE(𝜎[0]|| … ||𝜎[31])2. 𝑆 = DECI(𝜎[32]|| … ||𝜎[63])3. 𝐴′ = DECE(𝐴)114. 1.～3.でデコードに失敗した場合（𝑆が範囲外であることを含む），無効を出力して終了．
5. 𝑘 = DECI (SHA512(dom2(𝐹, 𝐶)||𝑅||𝐴||SHA512(𝑀))) mod 𝐿
6. [8][𝑆]𝐵 = [8]𝑅 + [8][𝑘]𝐴′ が成り立たない場合は無効を出力し，成り立つ
場合は有効を出力する．

3.1.7.

Ed448，Ed448ph 共通パラメータ

Ed448，Ed448ph では以下の共通パラメータを使用する．
① 𝑝 = 2448 − 2224 − 1（edwards448 [7]の𝑝）② 𝑏 = 456
③ 𝑐 = 2（edwards448 [7]の補因子の 2 を底とする対数）④ 𝑛 = 447
⑤ 𝑑 = −39081（edwards448 [7]の𝑑）⑥ 𝑎=1⑦ 𝐵 = (224580040295924300187604334099896036246789641632564134
24612546168695041546740603290902919286935795328257803207514
6446173674602635247710,298819210078481492676017930443930673
43754404015408024209592824137233150618983587600353687865541
8784733982303233503462500531545062832660))（edwards448 [7]の(𝑋(𝑃), 𝑌(𝑃)）⑧ 𝐿 = 2446 + 13818066809895115352007386748515426880336692474882
178609894547503885（edwards448 [7]の位数）

3.1.8.

Ed448，Ed448ph 共通処理

以下の処理は EdDSA448，EdDSA448ph で共通である．

① 点の加算，2 倍算（同一の点の加算），無限遠点との加算
楕円点の加算，2 倍算（同一の点の加算），無限遠点との加算は以下の 1 つの式で計算できる．
𝑥1 𝑦2 + 𝑥2 𝑦1
𝑦1 𝑦2 − 𝑥1 𝑥2
𝑥3 =, 𝑦3 =
1 + 𝑑𝑥1 𝑥2 𝑦1 𝑦2
1 − 𝑑𝑥1 𝑥2 𝑦1 𝑦2
これを RFC8032 [2]で推奨される射影座標系（projective coordinates）（3.2.1 参照）で計算するアルゴリズムは以下のようになる．
入力：加算する点𝑃1 = (𝑋1 , 𝑌1 , 𝑍1 )，点𝑃2 = (𝑋2 , 𝑌2 , 𝑍2 )出力：加算結果の点𝑃3 = 𝑃1 + 𝑃2 = (𝑋3 , 𝑌3 , 𝑍3 )1. 𝐴 = 𝑍1 ⋅ 𝑍2

12

2. 𝐵 = 𝐴2
3. 𝐶 = 𝑋1 ⋅ 𝑋2
4. 𝐷 = 𝑌1 ⋅ 𝑌2
5. 𝐸 = 𝑑 ⋅ 𝐶 ⋅ 𝐷
6. 𝐹 = 𝐵 − 𝐸
7. 𝐺 = 𝐵 + 𝐸
8. 𝐻 = (𝑋1 + 𝑌1 )(𝑋2 + 𝑌2 )9. 𝑋3 = 𝐴 ⋅ 𝐹 ⋅ (𝐻 − 𝐶 − 𝐷)
10. 𝑌3 = 𝐴 ⋅ 𝐺 ⋅ (𝐷 − 𝐶)
11. 𝑍3 = 𝐹 ⋅ 𝐺② 2 倍算の高速化
楕円点の 2 倍算は①で計算できるが，入力が同一の点かどうか条件分岐してもよい
場合は高速なアルゴリズムを使うこともできる．射影座標系（3.2.1 参照）で計算するアルゴリズムは以下のようになる．
入力：2 倍算する点𝑃1 = (𝑋1 , 𝑌1 , 𝑍1 )
出力：2 倍算結果の点𝑃3 = 𝑃1 + 𝑃1 = (𝑋3 , 𝑌3 , 𝑍3 )1. 𝐵 = (𝑋1 + 𝑌1 )2
2. 𝐶 = 𝑋12
3. 𝐷 = 𝑌12
4. 𝐸 = 𝐶 + 𝐷
5. 𝐻 = 𝑍12
6. 𝐽 = 𝐸 − 2𝐻
7. 𝑋3 = (𝐵 − 𝐸) ⋅ 𝐽
8. 𝑌3 = 𝐸 ⋅ (𝐶 − 𝐷)9. 𝑍3 = 𝐸 ⋅ 𝐽③ dom4(𝑥, 𝑦)
入力：0〜255 の値𝑥，最大で 255 バイトのデータ列𝑦
出力：バイト列
1. バイト列"SigEd448"||OCTET(𝑥)||OCTET(OLEN(𝑦))||𝑦を出力する．
"SigEd448"は ASCII 文字列(8 バイト)とする．

④ 鍵生成
入力：なし
出力：秘密鍵𝑘，公開鍵𝐴
1. 𝑘 =暗号的に安全なランダムデータの 57 オクテット

132. ℎ = SHAKE256(𝑘,114)（114 オクテット）
3. ℎ[0]0 = ℎ[0]1 = 0，ℎ[55]7 = 1，ℎ[56] = 0
4. 𝑠 = DECI(ℎ[0]|| … ||ℎ[56]) mod 𝐿
5. 𝐴 = ENCE([𝑠]𝐵)（32 オクテット）
秘密のスカラー値𝑠は 4 の倍数で，正確に 448 ビットとなる．

3.1.9.

Ed448

0 バイト以上のコンテキストを入力し，ハッシュ値を保持しない，Edwards448 を使った EdDSA である．

① 署名生成入力：秘密鍵𝑘（57 オクテット），メッセージ𝑀（任意のサイズのオクテット列），最小 0 オクテット，最大 255 オクテットのコンテキスト𝐶，フラグ𝐹 = 0（既定値）
出力：署名𝜎1. ℎ = SHAKE256(𝑘,114)（114 オクテット）
2. ℎ[0]0 = ℎ[0]1 = 0，ℎ[55]7 = 1，ℎ[56] = 0
3. 𝑠 = DECI(ℎ[0]|| … ||ℎ[56]) mod 𝐿
4. 𝐴 = ENCE([𝑠]𝐵)（57 オクテット）
5. 𝑟 = DECI(SHAKE256(dom4(𝐹, 𝐶)||ℎ[57]||. . . ||ℎ[113]||𝑀, 114)) mod 𝐿
6. 𝑅 = ENCE([𝑟]𝐵)（57 オクテット）
7. 𝑘 = DECI(SHAKE256(dom4(𝐹, 𝐶)||𝑅||𝐴||𝑀, 114)) mod 𝐿
8. 𝑆 = (𝑟 + 𝑘 ∗ 𝑠) mod 𝐿
9. 𝜎 = 𝑅||ENCO(𝑆)（114 オクテット）
秘密のスカラー値𝑠は 4 の倍数で，正確に 448 ビットとなる．

② 署名検証
入力：署名𝜎（114 オクテット），公開鍵𝐴（57 オクテット），メッセージ𝑀（任意のサイズのオクテット列），最小 0 オクテット，最大 255 オクテットのコンテキスト
𝐶，フラグ𝐹 = 0（既定値）
出力：署名検証の結果（有効または無効）
1. 𝑅 = DECE(𝜎[0]|| … ||𝜎[56])2. 𝑆 = DECI(𝜎[57]|| … ||𝜎[113])
3. 𝐴′ = DECE(𝐴)4. 1.～3.でデコードに失敗した場合（0 ≤ 𝑆 < 𝐿の範囲外であることを含む），無効を出力して終了．
5. 𝑘 = DECI(SHAKE256(dom4(𝐹, 𝐶)||𝑅||𝐴||𝑀, 114)) mod 𝐿

14

6. [4][𝑆]𝐵 = [4]𝑅 + [4][𝑘]𝐴′ が成り立たない場合は無効を出力し，成り立つ
場合は有効を出力する．

3.1.10.

Ed448ph0 バイト以上のコンテキストを入力し，ハッシュ値を保持する，Edwards448 を使った EdDSA である．

① 署名生成入力：秘密鍵𝑘（57 オクテット），メッセージ𝑀（任意のサイズのオクテット列），最小 0 オクテット，最大 255 オクテットのコンテキスト𝐶，フラグ𝐹 = 1
出力：署名𝜎1. ℎ = SHAKE256(𝑘, 114)（114 オクテット）
2. ℎ[0]0 = ℎ[0]1 = 0，ℎ[55]7 = 1，ℎ[56] = 0
3. 𝑠 = DECI(ℎ[0]|| … ||ℎ[56]) mod 𝐿
4. 𝐴 = ENCE([𝑠]𝐵)（57 オクテット）
5. 𝑟 =
DECI(SHAKE256(dom4(𝐹, 𝐶)||ℎ[57]|| … ||ℎ[113]||SHAKE256(𝑀,64), 114))
mod 𝐿
6. 𝑅 = ENCE([𝑟]𝐵)（57 オクテット）
7. 𝑘 = DECI(SHAKE256(dom4(𝐹, 𝐶)||𝑅||𝐴||SHAKE256(𝑀,64), 114)) mod 𝐿
8. 𝑆 = (𝑟 + 𝑘 ∗ 𝑠) mod 𝐿
9. 𝜎 = 𝑅||ENCO(𝑆)（114 オクテット）
秘密のスカラー値𝑠は 4 の倍数で，正確に 448 ビットとなる．

② 署名検証
入力：署名𝜎（114 オクテット），公開鍵𝐴（57 オクテット），メッセージ𝑀（任意のサイズのオクテット列），最小 0 オクテット，最大 255 オクテットのコンテキスト
𝐶，フラグ𝐹 = 1
出力：署名検証の結果（有効または無効）
1. 𝑅 = DECE(𝜎[0]|| … ||𝜎[56])2. 𝑆 = DECI(𝜎[57]|| … ||𝜎[113])
3. 𝐴′ = DECE(𝐴)4. 1.～3.でデコードに失敗した場合（0 ≤ 𝑆 < 𝐿の範囲外であることを含む），無効を出力して終了．
5. 𝑘 = DECI(SHAKE256(dom4(𝐹, 𝐶)||𝑅||𝐴||SHAKE256(𝑀,64), 114)) mod 𝐿
6. [4][𝑆]𝐵 = [4]𝑅 + [4][𝑘]𝐴′ が成り立たない場合は無効を出力し，成り立つ
場合は有効を出力する．

15

3.2. 実装の解説
EdDSA のアルゴリズム特性を考慮した実装をする上での実現方法を検討可能な項目について解説する．

3.2.1.

Edwards 曲線の特徴

Edwards 曲線の特徴を実装面の観点で説明する．
• 加算と 2 倍算が同一式で演算可能
点の加算式
𝑥1 𝑦2 + 𝑥2 𝑦1 𝑦1 𝑦2 − 𝑎𝑥1 𝑥2(𝑥1 , 𝑦1 ) + (𝑥2 , 𝑦2 ) = ((1),)
1 + 𝑑𝑥1 𝑥2 𝑦1 𝑦2 1 − 𝑑𝑥1 𝑥2 𝑦1 𝑦2
では同一の点同士の加算を特別扱いせず，分岐なしで演算可能である．例えば，
ECDSA でよく使われる曲線では同一の点の場合，同一かどうかの判定と 2 倍専用の演算が必要である．
演算処理中に，秘密情報に依存した分岐が存在すると，Side Channel 情報3の分析によって，真の処理が行われたか，偽の処理が行われたかを推測し，分岐の条件となった秘密の情報を推測する Side Channel Attack（SCA）を行うことができる．
分岐なしで処理を行うことができれば，Side Channel 情報は秘密の情報によらず一定となるため，SCA への対策となる．
なお，署名検証処理では秘密情報を処理しないため，SCA に対する対策は不要であり，2 倍算専用のアルゴリズムで高速化が可能である．
•

無限遠点を座標(0,1)で計算可能
無限遠点が座標(0,1)であることにより式(1)で無限遠点を特別扱いせず，分岐なしで演算可能となる．例えば，ECDSA でよく使われる曲線では加算のオペラン
ドの片方または両方が無限遠点の場合，何もしないで無限遠点でないオペランドを出力する，という分岐が必要である．

これらの 2 つの特徴から次のことが言える．
• 点の加算，2 倍算がすべての点を例外なく，式(1)で演算可能
計算式のレベルで分岐や例外処理がないため，入力値によらず一定の処理時間
や一定の消費電力等で演算するような実装が可能であり，数式レベルで SCA に対して耐性を持っていると言える．
また，式が 1 つなので実装が簡素化できるため，省メモリを実現することにも
寄与する．

3

暗号装置の処理中に入出力とは別に暗号装置の外部に伝わる情報．処理時間，CPU の
消費電力，電圧，電磁波，音，熱など．

16

また，座標系を適切に選択することで高速化が可能である．
• 拡張射影座標
Ed25519 では拡張した射影座標系𝜀 𝑒 [15]で計算することが RFC8032 [2]で推奨
𝑋

𝑌𝑇されている．座標(𝑥, 𝑦)はこの座標系では𝑥 = 𝑍 , 𝑦 = 𝑍 , 𝑥𝑦 = 𝑍としたときの(𝑋, 𝑌, 𝑍, 𝑇)で表現される．この表現により，加算の式(1)から乗法逆元の計算が消え，処理コストの高い乗法逆元の計算がなくなることで以下のように式(1)をそのまま計算するより高速化できる．
(𝑋1 , 𝑌1 , 𝑍1 , 𝑇1 ) + (𝑋2 , 𝑌2 , 𝑍2 , 𝑇2 )= ((𝑋1 𝑌2 + 𝑋2 𝑌1 )(𝑍1 𝑍2 − 𝑑𝑇1 𝑇2 ), (𝑌1 𝑌2 + 𝑋1 𝑋2 )(𝑍1 𝑍2 + 𝑑𝑇1 𝑇2 ), (𝑍1 𝑍2+ 𝑑𝑇1 𝑇2 )(𝑍1 𝑍2 − 𝑑𝑇1 𝑇2 ), (𝑋1 𝑌2 + 𝑋2 𝑌1 )(𝑌1 𝑌2 + 𝑋1 𝑋2 ))•拡張射影座標系では無限遠点(0,1)は，𝑍を非ゼロの任意の元として(0, 𝑍, 𝑍, 0)
となる．
射影座標
Ed448 では射影座標系 [4]で計算することが RFC8032 [2]で推奨されている．
𝑋𝑌

座標(𝑥, 𝑦)はこの座標系では𝑥 = 𝑍 , 𝑦 = 𝑍としたときの(𝑋, 𝑌, 𝑍)で表現される．この表現により，加算の式(1)から乗法逆元の計算が消え，処理コストの高い乗法逆元の計算がなくなることで以下のように式(1)をそのまま計算するより高速化できる．
(𝑋1 , 𝑌1 , 𝑍1 ) + (𝑋2 , 𝑌2 , 𝑍2 )= ((𝑋1 𝑌2 𝑍1 𝑍2 + 𝑋2 𝑌1 𝑍1 𝑍2 )(𝑍1 𝑍2 𝑍1 𝑍2 − 𝑑𝑋1 𝑋2 𝑌1 𝑌2 ), (𝑌1 𝑌2 𝑍1 𝑍2− 𝑋1 𝑋2 𝑍1 𝑍2 )(𝑍1 𝑍2 𝑍1 𝑍2 + 𝑑𝑋1 𝑋2 𝑌1 𝑌2 ), (𝑍1 𝑍2 𝑍1 𝑍2 + 𝑑𝑋1 𝑋2 𝑌1 𝑌2 )(𝑍1 𝑍2− 𝑑𝑋1 𝑋2 𝑌1 𝑌2 ))射影座標系では無限遠点(0,1)は，𝑍を非ゼロの任意の元として(0, 𝑍, 𝑍)とな
る．

3.2.2.

EdDSA の特徴

EdDSA の特徴を実装面の観点で説明する．
•

推奨パラメータが固定
RFC8032 [2]ではパラメータに依存しない汎用的な EdDSA についても説明されているが，Ed25519 と Ed448 を使用した特定のパラメータを使用した実装を推奨している．これにより扱う素体，曲線およびハッシュアルゴリズム等が固定化され，実装では使用するメモリ量をあらかじめ計画することが可能となっている．
これにより動的にメモリを確保する必要がなく，あらかじめ必要な固定量のメモリを確保しておき，そのメモリ上ですべて処理をすることが可能である．
EdDSA の考案者である Daniel J. Bernstein が公開しているリファレンス実装の署名生成関数 crypto_sign（図 4）を例に挙げると，unsigned char の配列（バイト列）を変数 pk，az，nonce および hram として固定の要素数でスタック

17

領域に確保している．また，sc25519 構造体（図 1）の変数 sck，scs およびscsk，ge25519 構造体（図 3）の変数 ger，ここでは使用していないが fe25519
構造体（図 2）も固定長であり，スタック上に確保している．
このようなスタック上の固定長のメモリ確保は，コンパイル時に必要な総量が計算される．コンパイルで生成される命令はスタックポインタを固定バイト進める命令のみとなるため高速化が期待できる．

図 1 sc25519 構造体

図 2 fe25519 構造体

図 3 ge25519 構造体

18

図 4 署名生成関数 crypto_sign（sign.c）•

分岐のないアルゴリズム
入力によって分岐することがないアルゴリズムとなっており，また，呼び出す
Edwards 曲線上の演算，素体の演算等も分岐のない実装とすることが可能である．これにより前項のメモリに対して「どこをいつ書き換えるか」や「どこをいつ参照するか」が入力によらず固定化できる．
これは更新/参照するメモリアドレスの計算を入力値によらず固定化できることになり，高速化，および SCA への耐性になる．

•

乱数生成は秘密鍵生成時のみでの使用
EdDSA では乱数を鍵生成でのみ使用している．この乱数は秘密鍵に直接影響を与えるため，暗号的に安全である必要がある．一方で，署名生成，署名検証では乱数を使用しない．一般的に，暗号的に安全な乱数は生成の時間がランダムで処19

理コストが高い．EdDSA では署名生成，署名検証を一定時間で行い，乱数を使用するアルゴリズムに比べて高速に処理することができる．

3.2.3.

RFC8032 に記載されている注意点

RFC8032 [2]において，Security Considerations として安全性の観点からいくつかの実装上の注意点を挙げられている．実装時に参考すべき項目について，参考情報として以下に概要を示す．
① Edwards 曲線上の点の加算は SCA に耐性があるが，GF(𝑝)の演算ではキャリーの伝搬等に依存した分岐をしてはならない．スカラー倍ではバイナリ法を使って 1ビットずつ処理し，SCA 耐性のある条件付き代入を行うと単純である．
② 複数の署名を同時検証する高速化手法の中には，乱数が必要なものがある．
③ プロトコルが指定した定数をコンテキストに使用すること．メッセージに依存したコンテキストは使用するべきでなく，状況によってコンテキストを変えるべきではない．
④ Ed25519ph と Ed448ph はハッシュ関数の強度に依存するため，既存 API（分割デー
タ入力等）との互換性を考慮しても使用すべきではない．Ed25519 は品質の高い実装が多いため，128 ビットの安全性で十分な場合は Ed25519 を，それ以外の場合は
Ed448 を推奨する．
⑤ Ed25519，Ed25519ctx，および Ed25519ph に同じ鍵ペアを使用できる．Ed448 および Ed448ph も同様．
⑥ 少なくとも 2 回の操作が必要なため，一度に大量のデータに署名することは避ける．一定量のバッファのみを備えた Init/Update/Finalize インターフェースを使用して Ed25519/Ed448 署名を作成できるように，Ed25519/Ed448 の署名生成機能を変更することは勧めない．
⑦ 署名検証の等式でコファクタ倍することは安全性の面で必須ではないが，一部のアプリケーションでは正確な署名を定めないと指紋攻撃等を引き起こすことがある．

20

3.2.4.

SCA 対策3.2.1 および 3.2.2 で示したように EdDSA は SCA への耐性をもったアルゴリズムであるが，3.2.3 の①でも言及したように，SCA 耐性を下げるような実装も可能であることに注意する．なお，署名検証でのスカラー倍は秘密にするべき情報が何もないのでここに書いたような注意は不要である．
•

条件付きの代入
ビット𝑏が 1 の場合だけ既存の変数𝑟に𝑥を代入する処理を考える．
条件により代入する／しないが変わる処理を CPU 命令の用語で Conditional Move，
CMOV と呼び，専用の命令が用意されている．アセンブラ言語や機械語が利用できる場
合は利用してもよいが，C 言語や Java 等でこの処理を実装する場合は注意が必要となる．
単純な実装はif 𝑏 = 1 then 𝑟 = 𝑥 endif
であるが，代入処理の有無の差のサイドチャネル情報によってビットの値が漏れる可能性がある．このような分岐を避けるため，以下のような演算を行う．
M = 𝑏𝑏𝑏…𝑏𝑏𝑏
𝑟 = 𝑟 ⊕ (M ∧ (𝑥 ⊕ 𝑟))
ここでMは𝑥と同じビット数のビット列で各ビットは𝑏とし，⊕はビットごとの排他的論理和，∧はビットごとの論理積とする．
𝑏 = 0の場合はM = 000…000となり，M ∧ (𝑥 ⊕ 𝑟)も000…000となるため，𝑟 = 𝑟 ⊕000…000が行われ，結果的に代入を行わないのと同じである．
𝑏 = 1の場合はM = 111…111となり，M ∧ (𝑥 ⊕ 𝑟)は𝑥 ⊕ 𝑟となるため，𝑟 = 𝑟 ⊕ 𝑥 ⊕ 𝑟が行われ，結果的に𝑟 = 𝑥と同じである．
どちらの場合も𝑏の値によらず同じ演算を行っている点に注意する．
Ed25519 のリファレンスコードでは（図 5）のような実装が使われている．

図 5 リファレンスコードにおける条件付き代入の例

ここでは上記の数式を 32 ビットの crypto_uint32 単位で行っている．
mask の符号反転は，b が 1 の場合は mask=1→-1=111…111 を，b が 0 の場合は
mask=0→000…000 を作成している．
Ed25519 のリファレンスコードではこの fe25519_cmov を使い，スカラー値によらない一定の命令群で事前計算値を用いたスカラー倍を実現している．

21

•点の 2 倍算
点の加算𝑅 = 𝑅 + 𝑄を行う場合に，少しでも高速にしようと

if 𝑅 = 𝑄 then 𝑅 = 2𝑅 else 𝑅 = 𝑅 + 𝑄 endifとすると，加算と 2 倍算の差のサイドチャネル情報により，𝑅 = 𝑄となったタイミン
グが推測しやすくなり，そのタイミングをヒントにスカラー値が推測される可能性がある．
Edwards 曲線の加算と 2 倍算を同じ式で演算できる特性を活かし，分岐をせずに加算を行うほうがよい．

3.2.5.

長いメッセージに対する配慮

3.2.3 の④および⑥で言及されたように，RFC8032 [2]は巨大なメッセージや断続的なメッセージに対する署名を推奨しておらず，このような署名を可能にする IUF（Init，Update，Finalize）インターフェースも推奨していない．
一方で，既存のハッシュ関数や署名アルゴリズムのような実装の多くで，IUF イン
ターフェースが採用されており EdDSA を採用するにあたってインターフェースの互換性が問題になることがある．
推奨はされていないが，あくまでも互換性を保つための方法として，Ed25519ph を
例に IUF インターフェースを簡単に紹介する．

① Ed25519ph 署名生成
＜Init＞ SHA512(𝑀)のコンテキスト𝑐𝑡𝑥に対して Init を行う．
＜Update＞ 𝑐𝑡𝑥に対して，メッセージ𝑀で Update を行う．
＜Finalize＞ 𝑐𝑡𝑥に対して Finalize を行い，出力𝐻をメッセージとして，秘密鍵
𝑘，コンテキスト𝐶，フラグ𝐹 = 1を用いて Ed25519ctx の署名生成を行う．

② Ed25519ph 署名検証
＜Init＞ SHA512(𝑀)のコンテキスト𝑐𝑡𝑥に対して Init を行う．
＜Update＞ 𝑐𝑡𝑥に対して，メッセージ𝑀で Update を行う．
＜Finalize＞ 𝑐𝑡𝑥に対して Finalize を行い，出力𝐻をメッセージとして，署名𝜎，
公開鍵𝐴，コンテキスト𝐶，フラグ𝐹 = 1を用いて Ed25519ctx の署名検証を行う．

3.2.6.

パラメータ𝑛の選択[8]の p.3 の脚注において「RFC8032 の記述に従ったが𝑐 = 𝑛は安全性の観点からありえない．」との指摘がある．RFC8032 [2]の汎用的なアルゴリズム解説ではこの指摘通りの記述が発見された．

22

ただし，Ed25519 等の具体的なアルゴリズムのパラメータの説明においては
Ed25519，Ed25519ctx，Ed25519ph では𝑛 = 254と定義され，Ed448，Ed448ph では𝑛 =447と定義されており，これらの具体的なアルゴリズムの記述を忠実に実装していれば問題のある実装とはならない．

3.3. Ed25519 実装の解説
EdDSA の考案者である Daniel J. Bernstein によってリファレンス実装が公開されている．4
プログラムは SUPERCOP [16]の一部として公開されている．5
ルートディレクトリから見て supercop-20210604/crypto_sign/ed25519 のディレクト
リにソースが格納されている．
このリファレンス実装には 4 つの版があり，以下のような特徴を持っている．

• ref 版．性能よりも移植性を考慮して C 言語で記述されている．
汎用性を考慮してデータに 32 ビットレジスタを使用している．
構造も単純なため EdDSA のアルゴリズムを理解することが容易になっている．
射影座標系を使う点以外は，ほぼ RFC8032 [2]と RFC7748 [7]のアルゴリズムのままである．

• ref10 版．python で計算した事前計算値を使い，ref 版より高速になっている．
C 言語で記載されているが，Bernstein によって開発された qhasm（共通の記述から CPU ごとに最適化されたアセンブラソースを生成するツール）によってCPU に最適化されたアセンブラコードも含んでいる．

• amd64-51-30k 版．51 ビットベースの多倍長整数を使い，30kb の事前計算値を使う．
ref10 版をさらに高速化した版．C 言語，qhasm によるアセンブラ言語で実装されている．

• amd64-64-24k 版．64 ビットベースの多倍長整数を使い，24kb の事前計算値を使う．ref10 版をさらに高速化した版．C 言語，qhasm によるアセンブラ言語で実装されている．

4
5

https://ed25519.cr.yp.to/software.html
https://bench.cr.yp.to/supercop/supercop-20210604.tar.xz

23ここでは，アルゴリズムの特徴が把握しやすい ref 版について説明する．ref 版のファイル構成は図 6 のようになっている．

図 6 リファレンス実装 ref 版ファイル構成

各ソースファイルは以下のような内容となっている．

• fe25519.c GF(𝑝)上の有限体演算を行う．乗算は教科書法．2255 = 19 mod 𝑝，
2256 = 38 mod 𝑝を活用している．有限体の元（255 ビット）同士を乗算して510 ビットにとした後，上位(510 − 256 = 254)ビットは2256 の倍数とみなせる．これを2256 = 38 mod 𝑝により，38 の倍数として下位 256 ビットに加算する．この 38 の倍数を計算する関数が times38 として定義されている．有限体の元は 8 ビットごとに uint32 で保管するが，uint32 の 32 ビットのうち上位
24 ビットは計算途中の値を格納するためのバッファとなっている．計算の途中
で 8 ビットを超えた分は，後でまとめて処理される．𝑝による剰余算も加減算のたびに行わずに，いくつかの計算をしたのちにまとめて剰余算を行う．
（lazy reduction）• ge25519_base.data ベースポイント𝐵のための事前計算値．𝑂，𝐵，2𝐵，3𝐵，
4𝐵，𝑂，(28 + 1)𝐵，(28 + 2)𝐵，(28 + 3)𝐵，(28 + 4)𝐵，𝑂，…を格納．

• ge25519.c 楕円曲線上の点の群演算．幅 3 の符号付 Window 法．

24• keypair.c 公開鍵と秘密鍵の鍵ペアの生成．
• open.c 署名検証．
• sc25519.c 有限体演算以外の多倍長整数演算．多倍長整数は 32 ビット整数（のうち 8 ビットのみ使用）×32 個の配列．

• sign.c 署名生成．
トップレベルの関数は• crypto_sign_keypair 鍵ペア生成．
• crypto_sign 署名生成．
• crypto_sign_open 署名検証．
3.4. Ed448 実装の解説
Curve448 の考案者である Mike Hamburg によってリファレンス実装が公開されている．（SourceForge.net: Ed448-Goldilocks6）プログラムは以下の Git リポジトリで公開されている．
git://git.code.sf.net/p/ed448goldilocks/code ed448goldilocks-code
このプロジェクトでは，ビルド時に Python で相対パス build/src/GENERATED に C 言
語ソースを生成する仕組みになっている．
ここでは生成後の C 言語ソースについて解説する．
生成された C 言語ソースは図 7 のような構成になっている．

6

http://ed448goldilocks.sourceforge.net/

25

図 7 生成された C 言語ソースファイル構成

各ソースファイルは以下のような内容となっている．
• curve25519 ディレクトリ配下 Ed25519 実装➢ decaf.c 楕円曲線上の点の群演算．“Decaf: Eliminating cofactors
through point compression”7で示される高速化技法を実装．
➢ eddsa.c Ed25519 の実装．
➢ elligator.c “Elligator: Elliptic-curve points indistinguishable
from uniform random strings”8で示される技法の実装➢ scalar.c スカラー値の多倍長整数演算．
• decaf ディレクトリ配下 C++インタフェースヘッダ• ed448goldilocks ディレクトリ配下 Ed448 実装➢ decaf.c 楕円曲線上の点の群演算．“Decaf: Eliminating cofactors
through point compression”7 で示される高速化技法を実装．
➢ eddsa.c Ed448 の実装．
➢ elligator.c “Elligator: Elliptic-curve points indistinguishable
from uniform random strings”8 で示される技法の実装

7
8

https://www.shiftleft.org/papers/decaf/decaf.pdf
https://elligator.cr.yp.to/elligator-20130828.pdf

26

➢scalar.c スカラー値の多倍長整数演算．
• p448 ディレクトリ配下 Ed448 のGF(𝑝)上の有限体演算➢ f_field.h 有限体演算のヘッダファイル．
➢ f_generic.c 有限体演算の実装．
• p25519 ディレクトリ配下 Ed25519 のGF(𝑝)上の有限体演算➢ f_field.h 有限体演算のヘッダファイル．
➢ f_generic.c 有限体演算の実装．
トップレベルの関数は，以下に示す通りである．
• decaf_ed448_derive_public_key（秘密鍵から公開鍵を生成する）• decaf_ed448_sign（Ed448 の署名生成の実装，秘密鍵と公開鍵が別引数）• decaf_ed448_sign_prehash（Ed448ph の署名生成の実装，秘密鍵と公開鍵が別引数）• decaf_ed448_keypair_sign（Ed448 の署名生成の実装，鍵ペアが引数）• decaf_ed448_keypair_sign_prehash（Ed448ph の署名生成の実装，鍵ペアが引数）• decaf_ed448_verify（Ed448 の署名検証の実装）• decaf_ed448_verify_prehash（Ed448ph の署名検証の実装）

27

4. EdDSA の標準化動向や OSS に関する採用状況など
EdDSA のアルゴリズムは 2011 年に発明された，近年標準化が進んでいるアルゴリズ
ムであるため，EdDSA のアルゴリズムが記載された標準や EdDSA を利用する標準について改めて採用状況を調査することで，EdDSA の標準化動向の全体像を把握することにつながると考えられる．
ただし，EdDSA が標準化されているだけは実社会で利用されるための状況には遠いと考えられ，OSS など実際のシステムやサービスなどで利用可能にする環境が実社会での利用について大きく寄与すると考えられる．このため，OSS で実装されているかどうかという観点が，広く利用されているかを把握するために有益であると考える．
本調査では，ハードウェアやソースコードの調査ができない商用ソフトウェアなどについては，EdDSA を実装しているかの判断をすることが困難であると考えるため，
本調査対象から除外することとした．
これらのことを踏まえて，EdDSA アルゴリズムに関して標準化されているかどうかの調査結果を 4.1 節にまとめ，さらに，4.1 節で抽出された標準仕様を参照する形式
で標準仕様において採用されているかの調査結果を 4.2 節にまとめる．また，企業・団体が実装し，ソースコードの調査が可能な OSS に焦点を絞った実装の調査結果を4.3 にまとめ，EdDSA の実装に対して発見されている脆弱性について調査結果を 4.4 節にまとめた．

4.1. EdDSA に関する標準化動向調査
本調査対象である EdDSA に関する標準化動向を調査する．標準化動向を調査するた
めに調査効率化を考慮して，インターネット上で公開されている情報に対して検索エンジンを用いて，以下に示す(A)群と(B)群の検索キーワードの組み合わせを使用して検索し，各検索結果のサイトやそのリンク先を調査することとした．
(A) "EdDSA"，"25519"，"448"(B) "specification" "standard"
調査した範囲では表 1 の 3 件が該当した．

28

表 1 EdDSA に関する標準化動向調査

項番

発行組織

1

IETF

ドキュメント名概要

発行日

RFC8032“EdwardsCurve Digital Signature Algorithm(EdDSA)”9

ディジタル署名方式である Edwards-curve Digital

2017 年 1 月

Signature Algorithm(EdDSA)を説明するドキュメ
ント．推奨する
edwards25519，edwards448
曲線で実体化されたアルゴ
リズム，サンプル実装およびテストベクトルを提供し
ている．

2

NIST

FIPS Pub 186-5(Draft) “Digital
Signature Standard(DSS)”10

ディジタル署名を生成するのに利用可能なアルゴ
リズム群を規定する標準．
RFC8032 を参照しているが，Ed25519ctx は規定されず，Ed25519，Ed448，
Ed25519ph，Ed448ph が規定されている．

2019 年 10 月

3

NIST

SP800-186 (Draft)“Recommendations
for Discrete Logarithm-Based Cryptography: Elliptic
Curve Domain Parameters”11

米国政府での利用で推奨される曲線を規定する．
素体と 2 の拡大体上のWeierstrass 曲線および，効率，side-channel
耐性および，実装の簡素化を主張する新しいMontgomery 曲線とその代替表現を規定する．新しい曲線は，IETF の CFRGで規定された曲線と相互運用可能である．

2019 年 10 月

9

表記上の問題が 5 件報告されているが，処理内容についての指摘はない．
https://csrc.nist.gov/publications/detail/fips/186/5/draft11
https://csrc.nist.gov/publications/detail/sp/800-186/draft
1029

EdDSA のアルゴリズムを標準仕様として規定しているのは RFC8032 のみという結果となった．また，Draft 版ではあるが，NIST の FIPS Pub 186-5 (Draft) [12]，SP800-186 にも RFC8032 [2]と相互運用可能なアルゴリズム（Ed25519，Ed448，
Ed25519ph，Ed448ph）が記載されていた．なお，Ed25519ctx は規定されていないという状況となっていた．
現在，Draft である FIPS Pub 186-5 (Draft) [12]および SP800-186 について，正式な文書として公開されるかどうかの情報について，今回調査した範囲では発見することはできなかった．しかし，2020 年 1 月 29 日に締め切られた Public comment では，
Draft 版の記述の誤りを指摘するコメントが多かったが，RFC8032 [2]との互換性を保つためのコメントや，RFC8032 [2]との互換性を保ちつつ，更に安全性を高められるオ
プションを望むコメントなど，すでに RFC8032 [2]が受け入れられている状況を考慮したと思われるコメントもあった．以上のことから，EdDSA は近い将来，NIST によって承認されたアルゴリズムに含まれると考える．

4.2. 標準仕様における EdDSA に関する採用状況
EdDSA の標準化動向の全体像を把握するため，4.1 で抽出されたリストにある EdDSA
アルゴリズムに関する標準化仕様を参照する形式で EdDSA がどのような標準仕様（Draft も含む）で利用されているかどうかを調査する．具体的には，4.1 で抽出されたリストのドキュメントを参照する標準化仕様にはどのようなものがあるかを以下のように調査した．
調査効率化を考慮して，インターネット上で公開されている情報に対して検索エン
ジンで以下の(A)群と(B)群の検索キーワードの組み合わせを使用して検索し，各検索結果のサイトやそのリンク先を調査した．
(A) "RFC8032"，"FIP186-5"，"SP800-186"(B) "specification"，"standard"
また，4.1 の調査中に発見した情報についても RFC8032，FIP180-5，SP800-186 を参照している標準も結果に含めた．
さらに，IETF 標準化された仕様である RFC8032 については，Data Tracker というサービスを用いて RFC8032 を参照している RFC や Internet Draft（I-D）の一覧を抽出した．12
比較対象としての参照，例として挙げているだけのものは除外した．
調査した結果を表 2 に示す．

12

https://datatracker.ietf.org/doc/rfc8032/referencedby/30

表 2 標準仕様における EdDSA に関する採用状況

項番
1

発効組織
IETF

2

IETF

3

IETF

4

IETF

5

IETF

6

IETF

7

IETF

8

IETF

9

IETF

ドキュメント名
RFC7479: "Using Ed25519 in SSHFP Resource Records"
RFC8037: "CFRG Elliptic Curve DiffieHellman (ECDH) and Signatures in JSON
Object Signing and Encryption (JOSE)"
RFC8080: "Edwards-Curve Digital Security
Algorithm (EdDSA) for DNSSEC"
RFC8152: "CBOR Object Signing and Encryption (COSE)"
RFC8410: "Algorithm Identifiers for
Ed25519, Ed448, X25519, and X448 for Use
in the Internet X.509 Public Key Infrastructure"
RFC8411: "Additional XML Security Uniform Resource Identifiers (URIs)"
RFC8419: "Use of Edwards-Curve Digital
Signature Algorithm (EdDSA) Signaturesin the Cryptographic Message Syntax(CMS)"
RFC8420: "Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in theInternet Key Exchange Protocol Version 2(IKEv2)"
RFC8422: "Elliptic Curve Cryptography(ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier"

31

公開年月
2015 年 3 月

Ed25519〇

Ed448
×参照している文献[1]

2021 年 1 月〇〇

RFC8032 [2]2021 年 2 月〇〇

RFC8032 [2]2021 年 7 月〇〇

RFC8032 [2]2021 年 8 月〇〇

RFC8032 [2]2021 年 8 月〇〇

RFC8032 [2]2021 年 8 月〇〇

RFC8032 [2]2021 年 8 月〇〇

RFC8032 [2]2021 年 8 月〇〇

RFC8032 [2]

項番
10

発効組織
IETF

11

IETF

12

IETF

13

IETF

14

IETF

15

IETF

16

IETF

17

IETF

18

IETF

19

IETF

ドキュメント名
RFC8446: "The Transport Layer Security(TLS) Protocol Version 1.3"
RFC8463: "A New Cryptographic Signature
Method for DomainKeys Identified Mail
(DKIM)"
RFC8550: "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 4.0
Certificate Handling"
RFC8551: "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 4.0
Message Specification"
RFC8591: "SIP-Based Messaging with
S/MIME"
RFC8624 "Algorithm Implementation Requirements and Usage Guidance for DNSSEC"
RFC8709: "Ed25519 and Ed448 Public Key
Algorithms for the Secure Shell (SSH)
Protocol"RFC8928: "Address-Protected Neighbor
Discovery for Low-Power and Lossy Networks"
Draft: "Additional XML Security Uniform
Resource Identifiers (URIs)"
Draft: "Alternative Elliptic Curve Representations"

32

公開年月
2021 年 8 月

Ed25519〇

Ed448〇

参照している文献
RFC8032 [2]2021 年 9 月〇

×RFC8032 [2]2021 年 4 月〇

×RFC8032 [2]2021 年 4 月〇

×RFC84192021 年 4 月〇

×RFC8032 [2]2021 年 6 月〇〇

RFC8032 [2]2021 年 2 月〇〇

RFC8032 [2]2021 年 11 月 〇×

RFC8032 [2]2021 年 11 月 〇〇RFC8032 [2]2021 年 10 月 〇〇RFC8032 [2]

項番
20

発効組織
IETF

ドキュメント名
Draft: "Certificate Management Protocol(CMP) Algorithms"

公開年月
Ed255192021 年 11 月 〇

Ed448
〇

21

IETF

2021 年 8 月

〇

×

22

IETF

2020 年 9 月〇〇

RFC8032 [2]

23

IETF

2021 年 12 月 〇〇RFC8032 [2]

24
25

IETF
IETF

2016 年 8 月 〇2021 年 10 月 〇

×
×

[1]
RFC8032 [2]

26

IETF

2021 年 10 月 〇〇RFC8032 [2]

27
28

IETF
IETF

2021 年 9 月 〇2021 年 10 月 〇×〇

RFC8032 [2]RFC8032 [2]

29

IETF

2021 年 8 月〇〇

RFC8032 [2]

30

IETF

2021 年 10 月 〇×

RFC8032 [2]

31

IETF

2021 年 8 月〇〇

RFC8032 [2]

32

IETF

Draft: "Certificate Transparency Version 2.0"
Draft: "CBOR Object Signing and Encryption (COSE): Initial Algorithms"
Draft: "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote Identification (UAS RID)"
Expired Draft: "EdDSA for OpenPGP"
Draft: "Group OSCORE - Secure Group
Communication for CoAP"
Draft: "Key Management for OSCORE
Groups in ACE"
Draft: "License Activation Protocol"
Draft: "Mathematical Mesh 3.0 Part II:
Uniform Data Fingerprint."
Draft: "Mathematical Mesh 3.0 Part
VIII: Cryptographic Algorithms"
Draft: "Message Queuing Telemetry
Transport (MQTT)-TLS profile of Authentication and Authorization for Constrained Environments (ACE) Framework"
Draft: "New Cryptographic Algorithms
for HIP"
Draft: "OpenPGP Message Format"

参照している文献
RFC8032 [2]FIPS Pub 186-5 (Draft)[12]
RFC8032 [2]2021 年 10 月 〇〇RFC8032 [2]

33

項番
33

発効組織
IETF

34
35

IETF
IETF

36

IETF

37

IETF

38

DMTF

39

ETSI

40

FIDO Alliance

41

FIDO Alliance

42

JCP

43

NIST

ドキュメント名
Draft: "S/MIME Example Keys and Certificates"
Draft: "The GNU Name System"
Draft: "The Messaging Layer Security(MLS) Protocol"
Draft: "The Transport Layer Security(TLS) Protocol Version 1.3"
Draft: "Threshold Modes in Elliptic
Curves"DSP0274 1.2.0WIP.90 "Security Protocol
and Data Model (SPDM) Specification"(Work in Progress Version)ETSI TS 102 809 V1.3.1 (2017-06) "Digital Video Broadcasting (DVB); Signallingand carriage of interactive applications
and services in Hybrid broadcast/broadband environments""FIDO Authenticator Allowed Cryptography List""FIDO Registry of Predefined Values"
Review Draft 02"Java SE 15 ( JSR 390)Final Release
Specification"
Draft: "ACVP EdDSA Algorithm JSON Specification"

34

公開年月
2021 年 8 月

Ed25519〇

Ed448
×参照している文献
RFC8032 [2]2021 年 11 月 〇2021 年 10 月 〇×〇

RFC8032 [2]RFC8032 [2]2021 年 10 月 〇〇RFC8032 [2]2021 年 8 月〇〇

RFC8032 [2]2021 年 8 月〇〇

RFC8032 [2]2017 年 6 月〇

×RFC8032 [2]2021 年 10 月 〇×

RFC8032 [2]2018 年 7 月〇

×RFC8032 [2]2020 年 9 月〇〇

RFC8032 [2]2021 年 11 月 〇〇FIPS Pub 186-5 (Draft)
[12]

項番

発効組織

44

OASIS

45

TCG

46

W3C

ドキュメント名"PKCS #11 Cryptographic Token Interface
Current Mechanisms Specification Version 3.0"
"TCG Algorithm Registry Family "2.0"
Level 00 Revision 01.32""Web Authentication: An API for accessing Public Key Credentials Level 2"

35

公開年月

Ed25519

Ed448

参照している文献

2020 年 6 月〇〇

RFC8032 [2]2021 年 6 月〇

×RFC8032 [2]2021 年 4 月〇

×RFC8152

ここで発見された 46 件のうち 37 件が IETF の RFC または I-D であり，IETF では
EdDSA を採用した標準化が活発であることが分かった．
また，参照している文献は，41 件が RFC8032 [2]を，2 件が [12]を，2 件が [1]を，1 件が RFC8419 を，1 件が RFC8152 を参照して [12]おり，正式に標準化された唯一の標準である RFC8032 [2]を採用する標準化仕様が多かった．
標準化の公開年月では，36 件が 2020 年と 2021 年に公開されており，2017 年のRFC8032 [2]の公開から 4 年を経て，急速に標準化仕様への採用が進んだと考えられる．
今回調査した範囲では，その他の団体の標準化もここ 2 年で行われており，全体的にここ 2 年で採用が進みつつあることが分かった．2022 年以降，NIST の FIPS Pub
186-5 が正式に発効した後はさらに採用が進み，2021 年末時点で Draft 版が多いことも考慮すると，2022 年以降はさらに採用が進むと予想される．
アルゴリズム別に調査結果を見ると，46 件のうち，Ed25519 を採用していたものが46 件だったのに対し，Ed448 を採用しているものは 28 件という結果となった．今回，実施した調査の範囲では Ed25519 と Ed448 における採用実績の差に関する差については判明できなかった．
以上から，標準化された EdDSA（主に Ed25519）については，2020 年から標準化仕様での採用によって広く利用される状況が整いつつあり，今後，採用する標準が増えるにつれ，さらに一般に広く受け入れられていくことが予想される．

4.3. EdDSA に関する OSS 採用状況
EdDSA が標準化された上で，実社会での利用に寄与する OSS など実際のシステムやサービスなどで利用可能な環境が整ってきているかどうかという観点が，EdDSA が広く利用されているかを把握するために有益であると考える．
このため，実際のシステムやサービスなどで利用可能な環境として利用される暗号ライブラリに焦点を当て，広く知られているメジャーな暗号ライブラリについて
EdDSA が実装されているかを調査した．
調査対象の暗号ライブラリを調査するために調査効率化を考慮して，インターネッ
ト上で公開されている情報に対して検索エンジンで"eddsa"，"library"，"open source"の検索キーワードを使用して検索し，検索結果のサイトやそのリンク先を調査した．
なお，ハードウェアやソースコードの調査ができない商用ソフトウェアなどについて
は，EdDSA を実装しているかの判断をすることが困難であるため OSS に限定した．
実装の確認は，EdDSA の処理手順が実装されているかソースコードを確認した．
Ed25519 と Ed448 のどちらが実装されているかは関数名やクラス名などの識別子で判断した．
表 3 の OSS が EdDSA を実装していた．

36

表 3 EdDSA の OSS による採用状況

項番
1

OSS 名
Apple Swift
CryptoApple

2

BoringSSL

Google3

Botanrandombit

4

Bouncy Castle

Legion of the
Bouncy Castle Inc.

5

blockchaincrypto-mpc

Unbound Security

6

CIRCL

CloudFlare7

cothority

Decentralized Distributed Systems
Laboratory

13
14

開発者

URL
https://github.com/apple/
swift-crypto
https://boringssl.
googlesource.com/boringssl/
https://github.com/randombit/botan
https://github.com/bcgit/bcjava

https://github.com/
unboundsecurity/blockchaincrypto-mpc
https://github.com/
cloudflare/circl
https://github.com/dedis/
cothority

実装箇所13/Sources/CCryptoBoringSSL/
crypto/curve25519/curve25519.c のED25519_sign 関数/crypto/curve25519/
curve25519.c の ED25519_sign 関数/src/lib/pubkey/ed25519/
ed25519.cpp の ed25519_sign 関数/core/src/main/java/org/
bouncycastle/math/ec/
rfc8032/Ed25519.java の Ed25519 ク
ラス
src/crypto_utils/
ec25519_core.cpp の ED25519_sign
関数/sign/ed25519/ed25519.go の signAll 関数/external/java/src/main/java/ch/epfl/dedis/lib/crypto/
SchnorrSig.java の SchnorrSig クラス

複数のソースファイルに実装されている場合は代表として Ed25519 の署名生成の実装箇所とした．
実装箇所に記載したソースコードの公開/更新日とした．

37

公開/更新日142021 年 8 月 17日
2021 年 5 月 28日2020 年 11 月 5日
2021 年 2 月 11日2019 年 2 月 14日2020 年 11 月 20
日2019 年 1 月 17
日

項番
8

OSS 名
eddsa

開発者
Invisible Internet
Project (I2P)

URL
https://github.com/str4d/
ed25519-java

9

goGoogle10Linux Foundation

11

Hyperledger
Iroha/irohaed25519
Libgcrypt

https://cs.opensource.google/go/go/+/master:
https://github.com/
hyperledger/iroha-ed25519

12

libsodiumlibsodium project

13

Monocypher

Monocypher

https://github.com/
LoupVaillant/Monocypher

14

NaCl

欧州委員会 CASE プ
ロジェクト

https://nacl.cr.yp.to/install.html

15NettleNiels Möller

16

Olm

Matrix.org Foundation

https://git.lysator.liu.se/
nettle/nettle
https://gitlab.matrix.org/
matrix-org/olm

The GnuPG project

https://git.gnupg.org/cgibin/gitweb.cgi?p=libgcrypt.
git;a=tree
https://github.com/jedisct1/
libsodium38

実装箇所13/src/net/i2p/crypto/eddsa/
EdDSAEngine.java のEdDSAEngine クラス
src/crypto/ed25519/ed25519.
go の sign 関数

公開/更新日142018 年 5 月 6日/lib/ed25519/ref10/ed25519.c のed25519_sign 関数

2019 年 2 月 15日

/cipher/ecc-eddsa.c の_gcry_ecc_eddsa_sign 関数

2021 年 5 月 17日/src/libsodium/crypto_sign/ed25519/ref10/sign.c のcrypto_sign_ed25519 関数/src/optional/
monocypher-ed25519.c のcrypto_ed25519_sign 関数
crypto_sign/
edwards25519sha512batch/ref/sign.c の crypto_sign 関数/eddsa-sign.c の_eddsa_sign 関数

2019 年 5 月 21日

/lib/ed25519/src/sign.c のed25519_sign 関数

2021 年 12 月 2日2020 年 5 月 3日2011 年 2 月 21日2020 年 11 月 9日2015 年 5 月 3
日

項番
17

OSS 名
OpenJDK

開発者
Oracle18

OpenSSLOpenSSL

19

SUPERCOP

VAMPIRE lab

20

wolfSSL

wolfSSL Inc.

URL
https://github.com/openjdk/
jdk

https://github.com/openssl/
openssl
http://bench.cr.yp.to/supercop.html
https://github.com/wolfssl/
wolfssl

39

実装箇所13/src/jdk.crypto.ec/share/classes/sun/security/ec/ed/
EdDSAOperations.java のEdDSAOperations クラス/crypto/ec/curve25519.c の
ossl_ed25519_sign 関数
crypto_sign/ed25519/
amd64-64-24k/sign.c のcrypto_sign 関数/wolfcrypt/src/ed25519.c の
wc_ed25519_sign_msg_ex 関数

公開/更新日142020 年 5 月 19日

2021 年 4 月 8日
2021 年 11 月 8日
2021 年 11 月 24日

Ed25519 についての採用は多く発見された一方で，Ed448 についての採用はほとんど発見されなかった．
また，多くの OSS がソース管理で利用している GitHub で EdDSA を検索すると 82 件のプロジェクトが検索条件に当てはまった．同様に Ed25519 を検索すると 673 件のプ
ロジェクトが検索条件に当てはまった一方で，Ed448 を検索すると 38 件のプロジェク
トが検索条件に当てはまった．
以上のことから，Ed25519 に比べて Ed448 の OSS 実装が少ないと言え，これは標準化仕様での採用状況にも関係していることが予想される．

4.4. EdDSA 実装の脆弱性に関する状況
OSS が EdDSA を採用しつつある中，基幹系システムや政府系システムなど，ミッションクリティカルなシステムでの利用が進むためには，動作が安定し，脆弱性がな
いことが重要となる．そのような成熟した実装とするためには，多くの人による様々な環境での動作確認に加え，専門家による実装の分析や脆弱性の指摘が行われ，正し
く修正されたことの確認まで行われる必要がある．
ここでは，専門家による脆弱性の指摘の状況を把握するため，EdDSA に関する脆弱性について NIST の脆弱性データベースに関する検索サイト15で調査を行った．
検索キーワードとして"eddsa"を用いて検索したところ，2 件の脆弱性に関する情報が発見された．

15

https://nvd.nist.gov/vuln/search

40NVD - CVE-2017-9526 (nist.gov)16

図 8 CVE-2017-9526

2017 年 6 月 10 日に公開された脆弱性である．
直接的には，Libgcrypt の脆弱性であるが，OS 等の多くの製品に影響する脆弱性である．
修正前は，セッション鍵を通常のメモリに保管したまま，そのセッション鍵で楕円曲線上の点の演算を行っていた．通常のメモリ上のセッション鍵で楕円曲線上の点の演算を行うと処理時間がセッション鍵の影響を受けるため，署名生成処理中の SCA に
よって攻撃者にセッション鍵が知られてしまい，長期秘密鍵も簡単に知られてしまう．
修正後は，セッション鍵は安全なメモリ上に保管され，楕円曲線上の点の演算の処
理時間はセッション鍵に依存せず一定時間となった．
Libgcrypt 1.7.7 以降では解消されている．

16

https://nvd.nist.gov/vuln/detail/CVE-2017-9526

41

NVD - CVE-2021-20305 (nist.gov)17

図 9 CVE-2021-20305

2021 年 4 月 5 日に公開された脆弱性である．
直接的には，Nettle の脆弱性であるが，OS 等多くの製品に影響する脆弱性である．
修正前は，GOST DSA，ECDSA，EdDSA の署名検証関数で，特定の署名に対して，範囲外のスカラー値で楕円曲線上の点のスカラー倍を実行し，誤った結果を生じる可能性があった．これにより攻撃者は不正な署名の検証を強制して，アサーションの失敗（クラッシュ）や不正な署名の検証成功を引き起こすことができた．最悪の場合，機密性，整合性，システムの可用性が脅かされる．
修正後は，範囲外のスカラー値はスカラー倍の前に修正されるようになった．これにより，不正な署名の検証を強制したとしても．サーションの失敗（クラッシュ）や不正な署名の検証成功を引き起こすことはできなくなった．
Nettle 3.7.2 以降では解消されている．

17

https://nvd.nist.gov/vuln/detail/CVE-2021-20305

42

5. 現在の電子政府推奨暗号リストに含まれる同技術分類の方式（ECDSA）との性能比較調査
現在，CRYPTREC では理論上の安全性等に関する外部評価を行ってきた．また，4 章の調査によって，標準仕様や OSS などにおいて EdDSA が世間で広く受け入れられつつあることが分かった．ここでは，実際にソフトウェアとして実装された EdDSA と，
CRYPTREC 暗号リストで電子政府推奨暗号リストに選択されている ECDSA の実装性能を比較調査する．

5.1. 性能比較調査について
性能比較調査では EdDSA と ECDSA を実測で比較する．
OSS により高速化技術にばらつきがあると予想されるため，1 つの OSS で ECDSA とEdDSA 両方が実装されたものを比較することが望ましい．
このため，広く知られているメジャーな暗号ライブラリから，Ed25519，Ed448 が実装され，安全性の近い ECDSA と EdDSA が両方実装されているものを選定して測定した．
また，本調査の実測は CPU やアーキテクチャが限定的であるが，第三者が行った多くの環境での性能比較結果を分析することで，CPU やアーキテクチャの違いによって
EdDSA と ECDSA の性能比較に影響があるかどうか補助的に確認し，5.3 節に記述した．
実測した測定結果を比較し，EdDSA の性能が ECDSA に比べてどのような特性を示すかを調査した．

5.2. ECDSA および EdDSA が実装されている OSS の選定
4.3 節で調査した広く知られているメジャーな暗号ライブラリから以下の条件を満たす OSS を選定した．（表 4）• Ed25519 および Ed448 が実装されている．
• 安全性の観点から評価対象である EdDSA と比較対象と妥当と想定される
ECDSA(P-256，P-384 および P-521)がすべて実装されている．
ボールド体のライブラリが条件を満たしていた．
表 4 ECDSA および EdDSA が実装されている選定した OSS 一覧

項番
1
2
3
4

暗号ライブラリApple Swift Crypto
BoringSSL
Botan
Bouncy Castle

EdDSA
Ed25519
Ed448
〇
×
〇
×
〇
×
〇
〇

43

P-256
〇
〇
〇
〇

ECDSA
P-384
〇
〇
〇
〇

P-521
〇
〇
〇
〇

項番
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

暗号ライブラリ
blockchain-crypto-mpc
CIRCL
cothority
eddsa
goHyperledger
Iroha/iroha-ed25519
Libgcrypt
libsodium
Monocypher
NaCl
NettleOlm
OpenJDKOpenSSLSUPERCOP
wolfSSLEdDSA
Ed25519
Ed448
〇
×
〇
〇
〇
×
〇
×
〇
×
〇
×
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇

〇
×
×
×
〇
×
〇
〇
〇
〇

P-256
〇
×
×
×
〇
×

ECDSA
P-384
〇
×
×
×
〇
×

P-521
〇
×
×
×
〇
×

〇
×
×
×
〇
×
〇
〇
〇
〇

〇
×
×
×
〇
×
〇
〇
〇
〇

〇
×
×
×
〇
×
〇
〇
〇
〇

5.3. 第三者による性能比較
本調査の実測は CPU やアーキテクチャが限定的であるが，4 章の調査中に発見された第三者が行った性能比較結果を分析することで，補助的に CPU やアーキテクチャの違いによって EdDSA と ECDSA の性能比較に影響があるかどうか確認した．

5.3.1.

eBATS による測定結果

eBATS は最も高速な公開鍵システムを探索するプロジェクトである．
European Network of Excellence for Cryptology II (ECRYPT II)18の一部である
Virtual Applications and Implementations Research Lab (VAMPIRE)19が構築し，現在も計測と記録が継続されている．
eBATS には SUPERCOP で計測した ECDSA および EdDSA の計測結果が記録されている．
なお，本サイトで，ECDSA P-XXX は ecdonaldpXXX，Ed25519 は ed25519，Ed448 は
ed448goldilocks という名前で記載されているが20，本報告書では ECDSA P-XXX，
Ed25519，Ed448 という表記に統一する．

18

https://www.ecrypt.eu.org/ecrypt2/
http://hyperelliptic.org/ECRYPTII/vampire/20
https://bench.cr.yp.to/impl-sign/ecdonaldp256.html
1944

図 10 Implementation comparison: crypto_sign/ecdonaldp256

ここでは，計測結果のサイト21から ECDSA P-256，ECDSA P-384，ECDSA P-521，
Ed25519，Ed448 の結果がそろっている，以下の 12 個の測定環境と各計測結果を抜き出した．
表 5 Implementation comparison: 測定環境

環境番号
[環境 1][環境 2][環境 3][環境 4][環境 5][環境 6][環境 7][環境 8][環境 9][環境 10][環境 11][環境 12]詳細
amd64; TigerLake (806c1); 2020 Intel Core i7-1165G7; 4 x
2800MHz; unstable; pascalinspiron75062n1, supercop-20210125
amd64; IceLake (706e5); 2020 Intel Core i5-1030NG7; 4 x 1100MHz;
icelake, supercop-20200826
amd64; Zen2 (830f10); 2019 AMD EPYC 7742; 64 x 2250MHz; unstable; colossus6, supercop-20210125
amd64; CometLake (806ec); 2019 Intel Core i3-10110U; 2 x
2100MHz; comet, supercop-20211108
amd64; CascadeLake (50657); 2019 Intel Core i9-10980XE; 18 x
3000MHz; avx512imath, supercop-20210125
amd64; CoffeeLake (906ea); 2018 Intel Xeon E-2124; 4 x 3300MHz;
r24000, supercop-20211108
amd64; Zen (800f12); 2017 AMD EPYC 7501; 32 x 2000MHz; unstable;colossus5, supercop-20210125
amd64; Zen (800f12); 2017 AMD EPYC 7451; 48 x 2300MHz; unstable;
firefly, supercop-20201130
amd64; Zen (800f11); 2017 AMD Ryzen 7 1700; 8 x 3000MHz; rumba7,
supercop-20211108
amd64; Zen (800f11); 2017 AMD Ryzen 5 1600; 6 x 3200MHz; rumba5,
supercop-20211108
amd64; Zen (800f11); 2017 AMD Ryzen 3 1200; 4 x 3100MHz; rumba3,
supercop-20200906
amd64; KabyLake (906e9); 2017 Intel Xeon E3-1220 v6; 4 x
3000MHz; kizomba, supercop-20211108

ここでは，計測結果のうち，鍵ペア生成（Cycles to generate a key pair），署名生成（Cycles to sign 59 bytes），署名検証（Cycles to verify 59 bytes）の処理にかかったサイクル数の中央値（四分位数の 50%）を抜粋した．

21

https://bench.cr.yp.to/results-sign.html

45

サイクル数が大きいと処理に時間が長く，サイクル数が小さいと処理の時間が短い
ことを示す．
また，本節のグラフでは縦軸はサイクル数を表している．

46

① 鍵ペア生成
表 6 鍵ペア生成におけるサイクル数計測結果の中央値
ECDSA P-256
ECDSA P-384
ECDSA P-521
Ed25519
Ed448

[環境1]
[環境2]
[環境3]
[環境4]
[環境5]
[環境6]
[環境7]
[環境8]
[環境9] [環境10] [環境11] [環境12]
146,136 146,442
76,523 106,062
95,752
97,081 117,020 148,166
117,481 117,843 120,094 108,705
5,599,777 3,280,399 2,434,410 3,379,855 3,281,797 3,286,632 3,561,460 4,499,559 3,553,883 3,549,587 3,573,060 3,340,724
1,211,113 7,502,147
511,852 717,799
710,068 707,880 838,820 984,653
841,169 840,831 864,838 711,153
80,195 114,320
33,59345,611
46,90545,66548,20061,66348,442
48,303
49,10445,764
315,396 139,697 121,388 153,872
182,441 153,474 237,300 330,694
200,014 199,763 199,702 153,332

47

128 ビットセキュリティの ECDSA P-256 と Ed25519 を比較したグラフを図 11 に示
す．

鍵ペア生成におけるECDSA P-256とEd25519のサイクル数比較
160,000
140,000
120,000
100,000
80,00060,00040,00020,0000[環境1] [環境2] [環境3] [環境4] [環境5] [環境6] [環境7] [環境8] [環境9] [環境10] [環境11] [環境12]

ECDSA P-256

Ed25519

図 11 鍵ペア生成における ECDSA P-256 と Ed25519 のサイクル数比較

図 11 から，12 環境中 12 環境で ECDSA P-256 より Ed25519 が少ないサイクル数で鍵ペアを生成できており，CPU 等の環境によらず EdDSA の鍵ペア生成のほうが高速であることが分かった．
192 ビットセキュリティの ECDSA P-384，256 ビットセキュリティの ECDSA P-521，
224 ビットセキュリティの Ed448 を比較したグラフを図 12 に示す．

48

鍵ペア生成におけるECDSA P-384とECDSA P-521，Ed448のサイクル数比較
8,000,000
7,000,000
6,000,000
5,000,000
4,000,000
3,000,000
2,000,000
1,000,000

0[環境1] [環境2] [環境3] [環境4] [環境5] [環境6] [環境7] [環境8] [環境9] [環境10] [環境11] [環境12]

ECDSA P-384

ECDSA P-521

Ed448

図 12 鍵ペア生成における ECDSA P-384 と ECDSA P-521，Ed448 のサイクル数比較

図 12 から，12 環境中 11 環境で ECDSA P-384 より ECDSA P-521 が少ないサイクル数
で鍵ペアを生成できており，[環境 2]だけ ECDSA P-384 より ECDSA P-521 が遅いことが分かる．[環境 2]は SUPERCOP のバージョンが最も古いことから，それ以降のSUPERCOP では ECDSA P-521 の実装が高速化されたと推測される．
ECDSA と EdDSA の比較という観点では，12 環境中 12 環境で ECDSA P-384，ECDSA P521 より Ed448 が少ないサイクル数で鍵ペアを生成できており，CPU 等の環境によらず
EdDSA の鍵ペア生成のほうが高速であることが分かった．

49

② 署名生成
表 7 署名生成におけるサイクル数計測結果の中央値
ECDSA P-256
ECDSA P-384
ECDSA P-521
Ed25519
Ed448

[環境1]
[環境2]
[環境3]
[環境4]
[環境5]
[環境6]
[環境7]
[環境8]
[環境9] [環境10] [環境11] [環境12]
196,904 201,443
98,978 144,568
130,219 133,710 151,300 192,717
151,779 151,768 154,814 141,272
5,986,180 3,468,754 2,536,267 3,494,435 3,416,282 3,415,800 3,707,800 4,636,777 3,702,111 3,696,594 3,725,332 3,432,919
1,839,049 8,064,420
782,370 1,094,418 1,078,906 1,073,777 1,284,780 1,481,982 1,283,307 1,284,174 1,284,299 1,081,181
85,034 117,932
35,46048,79650,02348,74451,06067,18351,30051,19452,514
48,740330,815 146,873 126,653 161,783
189,019 161,084 246,280 342,907
206,307 206,964 206,677 160,529

50

128 ビットセキュリティの ECDSA P-256 と Ed25519 を比較したグラフを図 13 に示
す．

署名生成におけるECDSA P-256とEd25519のサイクル数比較
250,000

200,000

150,000

100,000

50,0000[環境1] [環境2] [環境3] [環境4] [環境5] [環境6] [環境7] [環境8] [環境9] [環境10] [環境11] [環境12]

ECDSA P-256

Ed25519

図 13 署名生成における ECDSA P-256 と Ed25519 のサイクル数比較

図 13 から，12 環境中 12 環境で ECDSA P-256 より Ed25519 が少ないサイクル数で署名を生成できており，CPU 等の環境によらず EdDSA の署名生成のほうが高速であることが分かった．
192 ビットセキュリティの ECDSA P-384，256 ビットセキュリティの ECDSA P-521，
224 ビットセキュリティの Ed448 を比較したグラフを図 14 に示す．

51

署名生成におけるECDSA P-384とECDSA P-521，Ed448のサイクル数比較
9,000,000
8,000,000
7,000,000
6,000,000
5,000,000
4,000,000
3,000,000
2,000,000
1,000,000
0[環境1] [環境2] [環境3] [環境4] [環境5] [環境6] [環境7] [環境8] [環境9] [環境10] [環境11] [環境12]

ECDSA P-384

ECDSA P-521

Ed448

図 14 署名生成における ECDSA P-384 と ECDSA P-521，Ed448 のサイクル数比較

図 14 から，12 環境中 11 環境で ECDSA P-384 より ECDSA P-521 が少ないサイクル数
で署名を生成できており，[環境 2]だけ ECDSA P-384 より ECDSA P-521 が遅いことが分かる．[環境 2]は SUPERCOP のバージョンが最も古いことから，それ以降の SUPERCOP
では ECDSA P-521 の実装が高速化されたと推測される．
ECDSA と EdDSA の比較という観点では，12 環境中 12 環境で ECDSA P-384，ECDSA P521 より Ed448 が少ないサイクル数で署名を生成できており，CPU 等の環境によらず
EdDSA の署名生成のほうが高速であることが分かった．

52

③ 署名検証
表 8 署名検証におけるサイクル数計測結果の中央値
ECDSA P-256
ECDSA P-384
ECDSA P-521
Ed25519
Ed448

[環境1]
[環境2]
[環境3]
[環境4]
[環境5]
[環境6]
[環境7]
[環境8]
[環境9] [環境10] [環境11] [環境12]469,712 397,681 217,260 294,201
282,072 283,645 335,040 382,674
336,801 336,971 339,388 279,030
4,607,722 2,829,899 1,949,625 2,737,884 2,658,879 2,662,617 2,852,800 3,930,033 2,827,335 2,833,127 2,912,605 2,598,478
3,520,035 6,299,129 1,480,545 2,053,835 2,037,256 2,028,732 2,433,560 2,816,051 2,430,981 2,433,120 2,436,910 2,029,163
277,176 389,141 123,998 166,294
167,960 164,961 182,480 222,019
182,148 182,150 182,962 165,246
1,050,136
509,133 404,280 510,254
576,488 506,935 754,040 975,200
637,525 640,953 637,360 507,970

53

128 ビットセキュリティの ECDSA P-256 と Ed25519 を比較したグラフを図 15 に示
す．

署名検証におけるECDSA P-256とEd25519のサイクル数比較
500,000
450,000
400,000
350,000

300,000
250,000
200,000
150,000
100,000
50,0000[環境1] [環境2] [環境3] [環境4] [環境5] [環境6] [環境7] [環境8] [環境9] [環境10] [環境11] [環境12]

ECDSA P-256

Ed25519

図 15 署名検証における ECDSA P-256 と Ed25519 のサイクル数比較

図 15 から，12 環境中 12 環境で ECDSA P-256 より Ed25519 が少ないサイクル数で署名を検証できており，CPU 等の環境によらず EdDSA の署名検証のほうが高速であることが分かった．
192 ビットセキュリティの ECDSA P-384，256 ビットセキュリティの ECDSA P-521，
224 ビットセキュリティの Ed448 を比較したグラフを図 16 に示す．

54

署名検証におけるECDSA P-384とECDSA P-521，Ed448のサイクル数比較
7,000,000

6,000,000

5,000,000

4,000,000

3,000,000

2,000,000

1,000,000

0[環境1] [環境2] [環境3] [環境4] [環境5] [環境6] [環境7] [環境8] [環境9] [環境10] [環境11] [環境12]

ECDSA P-384

ECDSA P-521

Ed448

図 16 署名検証における ECDSA P-384 と ECDSA P-521，Ed448 のサイクル数比較

図 16 から，12 環境中 11 環境で ECDSA P-384 より ECDSA P-521 が少ないサイクル数
で署名を検証できており，[環境 2]だけ ECDSA P-384 より ECDSA P-521 が遅いことが分かる．[環境 2]は SUPERCOP のバージョンが最も古いことから，それ以降の SUPERCOP
では ECDSA P-521 の実装が高速化されたと推測される．
ECDSA と EdDSA の比較という観点では，12 環境中 12 環境で ECDSA P-384，ECDSA P521 より Ed448 が少ないサイクル数で署名を検証できており，CPU 等の環境によらず
EdDSA の署名検証のほうが高速であることが分かった．
以上の整理した eBATS における測定結果から，EdDSA は，同等または高い安全性の
ECDSA に比べて，CPU 等の環境によらず高速に動作することが分かった．

5.3.2.
論文“Is there a case to prefer Ed25519 over ECDSA
P-256 for DNSSEC?”での測定結果
University of Twente の J.J.Yu による“Is there a case to prefer Ed25519
over ECDSA P-256 for DNSSEC?”22によると，図 17，図 18 のような測定結果となったと報告している．

22

http://essay.utwente.nl/75354/1/DNSSEC%20curves.pdf

55

図 17 論文“Is there a case to prefer Ed25519 over ECDSA P-256 for DNSSEC?”
での測定結果（Table IV，ICV，IS）

図 18 論文“Is there a case to prefer Ed25519 over ECDSA P-256 for DNSSEC?”
での測定結果（Table ICS）

ここでは Intel の結果のみ引用したが，結論としては，ECDSA P-256 より最適化された Ed25519 のほうが性能がよいという結果を報告している．

56

5.3.3.
論文“Size, Speed, and Security: An Ed25519 Case
Study”での測定結果
Tampere University の Cesar Pereida García1 と Huawei Technologies の Sampo
Sovio による“Size, Speed, and Security: An Ed25519 Case Study”23によると図19 のような測定結果となったと報告している．

図 19 論文“Size, Speed, and Security: An Ed25519 Case Study”
での測定結果（Table 2，3）

これは Ed25519 のみ実装性能を測定したものであるが．最適化された高速な
Ed25519 では鍵生成が 60000 クロック，署名生成が 64000 クロック，署名検証が210000 クロックで処理が可能であることを報告している．

23

https://eprint.iacr.org/2021/471.pdf

57

CPU の種類等によって，どの程度の性能差が出るかは分かったが，OS，言語の違い
でどのような特性を示すかは分からなかった．

5.4. ECDSA および EdDSA に関する性能評価
本章では ECDSA と EdDSA の実測した性能比較結果について報告する．

5.4.1.

性能評価対象

ここでは，5.2 で選定した OSS について性能評価対象とする．
性能評価対象の OSS の詳細を表 9 に示す．
表 9 性能評価対象 OSS の詳細

項番
1
2
3
4
5
6

5.4.2.

OSS 名
Bouncy Castle
OpenJDK
Libgcrypt
Nettle（GMP を使用）
OpenSSL
wolfSSLバージョン
1.69
JDK 17
1.9.4
3.7.3（GMP は 6.2.1）
3.0.0
5.0.0

言語
Java
Java
C
C
C
C

性能測定方法

実機の Windows マシン，Linux マシン，Mac マシンを使い，実際の性能を測定した．
以下では，Windows のための記述には〈Win〉，Linux のための記述には〈Linux〉，
MacOS のための記述には〈Mac〉と記載する．
測定対象の OSS は，以下の方針で入手した．
• Java のライブラリは各 OS 向けにビルド済みの配布されているバイナリを入手した．
• C 言語のライブラリは，各 OS の一般的な開発環境でビルドする方法が開発者によって示されている場合，その開発環境でビルドする．各 OS の一般的な開発環
境として以下を想定した．
➢ 〈Win〉Microsoft Visual Studio Professional 2022 (64 ビット) Version
17.0.2（VS）➢ 〈Linux〉GNU Compiler Collection（gcc）(Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0➢ 〈Mac〉Apple Xcode 13.2
• 上記以外の場合，OS が当該バージョンをディストリビューションで配布している場合は配布されているものを利用する．

58

•

そのようなパッケージが存在しない場合，開発者が推奨する方法でビルドする．
OSS の個別の入手方法については，測定手順の中で後述する．
測定に使用した環境は以下のとおりである．
(1)〈Win〉計測マシン
CPU：Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz 2.59 GHz
搭載メモリ：32.0 GB
OS：Windows 10 Pro 21H1
シェル：コマンド プロンプト
Java：JDK 17.0.1 General-Availability Release24の Windows / x64 版を任意のディレクトリに展開し，Windows の環境変数 PATH に展開した jdk-17.0.1 の bin ディ
レクトリの絶対パスを追加することでインストールした．
➢ OpenJDK Runtime Environment (build 17.0.1+12-39)➢ OpenJDK 64-Bit Server VM (build 17.0.1+12-39, mixed mode, sharing)(2)〈Linux〉計測マシン
CPU：Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
搭載メモリ：32.0 GB
OS：Ubuntu 18.04.6 LTS
シェル：ターミナル（bash）
Java：コマンド
sudo apt install openjdk-17-jdkを実行することで Ubuntu パッケージをインストールした．
➢ OpenJDK Runtime Environment (build 17.0.1+12-Ubuntu-118.04)➢ OpenJDK 64-Bit Server VM (build 17.0.1+12-Ubuntu-118.04, mixed mode,sharing)(3)〈Mac〉計測マシン
CPU：2.3 GHz 8 コア Intel Core i9
搭載メモリ：64 GB 2667 MHz DDR4
OS：macOS Big Sur 11.4（20F71）
シェル：ターミナル（zsh）

24

https://jdk.java.net/17/

59Java：JDK 17.0.1 General-Availability Release24 の macOS /x64 版をスーパーユーザで/Library/Java/JavaVirtualMachines/に展開し，コマンド
export JAVA_HOME=`/usr/libexec/java_home -v17`を実行することでインストールした．
➢ Java(TM) SE Runtime Environment (build 17.0.1+12-LTS-39)➢ Java HotSpot(TM) 64-Bit Server VM (build 17.0.1+12-LTS-39, mixed
mode, sharing)
以下では，各 OSS について，各実行環境の入手方法，計測用プログラムの準備，計測用プログラムの実行方法について説明する．

① Bouncy Castle【OSS の入手】〈Win〉〈Linux〉〈Mac〉Bouncy Castle 1.69 を以下からダウンロードした．
https://www.bouncycastle.org/download/bcprov-jdk15on-169.jar【計測用プログラムの準備】
計測用プログラムは，ECDSA P-256，ECDSA P-384，ECDSA P-521，Ed25519，Ed448について⚫ KeyPairGenerator クラスの generateKeyPair メソッドでの鍵生成⚫ Signature クラスの initSign，update，sign メソッドを一連の処理としたブロックでの署名生成⚫ Signature クラスの initVerify，update，verify メソッドを一連の処理としたブロックでの署名検証
を，それぞれ103 回実行し，それぞれの103 回分の処理時間（ミリ秒）𝑡を測定する．
𝑡を103 で割ることでミリ秒から秒に変換し，得られた秒数で103 [回]を割ることで，スループット（1 秒あたりの実行回数）を求めた．計算式は
103
106
=
[回/秒]
(𝑡⁄103 )𝑡となる．
Libgcrypt 等，サポートしていない他のライブラリと合わせるため，Ed25519ph，
Ed25519ctx，Ed448ph は計測していない．
計測用プログラム EcDsaP256.java（図 20），EcDsaP384.java（図 21），
EcDsaP521.java（図 22），EdDsaEd25519.java（図 23）および EdDsaEd448.java（図24）を作成した．

60

図 20 Bouncy Castle EcDsaP256 計測用プログラム EcDsaP256.java61

図 21 Bouncy Castle EcDsaP384 計測用プログラム EcDsaP384.java62

図 22 Bouncy Castle EcDsaP521 計測用プログラム EcDsaP521.java63

図 23 Bouncy Castle Ed25519 計測用プログラム EdDsaEd25519.java64

図 24 Bouncy Castle Ed448 計測用プログラム EdDsaEd448.java

bcprov-jdk15on-169.jar，EcDsaP256.java，EcDsaP384.java，EcDsaP521.java，
EdDsaEd25519.java，EdDsaEd448.java を同一のディレクトリに配置し，そのディレク
トリ内で以下の内容のコマンドを実行して計測用プログラムをビルドした．

65

javac -classpath bcprov-jdk15on-169.jar -d . EcDsaP256.java
javac -classpath bcprov-jdk15on-169.jar -d . EcDsaP384.java
javac -classpath bcprov-jdk15on-169.jar -d . EcDsaP521.java
javac -classpath bcprov-jdk15on-169.jar -d . EdDsaEd25519.java
javac -classpath bcprov-jdk15on-169.jar -d . EdDsaEd448.java【計測用プログラムの実行方法】〈Linux〉〈Mac〉以下のコマンドを実行した．
java -classpath $PWD/bcprov-jdk15on-169.jar:$PWD bcBench.EcDsaP256
java -classpath $PWD/bcprov-jdk15on-169.jar:$PWD bcBench.EcDsaP384
java -classpath $PWD/bcprov-jdk15on-169.jar:$PWD bcBench.EcDsaP521
java -classpath $PWD/bcprov-jdk15on-169.jar:$PWD bcBench.EdDsaEd25519
java -classpath $PWD/bcprov-jdk15on-169.jar:$PWD bcBench.EdDsaEd448〈Win〉以下のコマンドを実行した．
java -classpath %CD%/bcprov-jdk15on-169.jar;%CD% bcBench.EcDsaP256
java -classpath %CD%/bcprov-jdk15on-169.jar;%CD% bcBench.EcDsaP384
java -classpath %CD%/bcprov-jdk15on-169.jar;%CD% bcBench.EcDsaP521
java -classpath %CD%/bcprov-jdk15on-169.jar;%CD% bcBench.EdDsaEd25519
java -classpath %CD%/bcprov-jdk15on-169.jar;%CD% bcBench.EdDsaEd448② OpenJDK【OSS の入手】〈Win〉〈Linux〉〈Mac〉Java 実行環境の機能を計測するため，別途の入手は不要
である．
【計測用プログラムの準備】
計測用プログラムは，ECDSA P-256，ECDSA P-384，ECDSA P-521，Ed25519，Ed448について⚫ KeyPairGenerator クラスの generateKeyPair メソッドでの鍵生成⚫ Signature クラスの initSign，update，sign メソッドを一連の処理としたブロックでの署名生成⚫ Signature クラスの initVerify，update，verify メソッドを一連の処理としたブロックでの署名検証
を，それぞれ103 回実行し，それぞれの103 回分の処理時間（ミリ秒）𝑡を測定する．

66

𝑡を103 で割ることでミリ秒から秒に変換し，得られた秒数で103 [回]を割ることで，スループット（1 秒あたりの実行回数）を求めた．計算式は
103
106
=
[回/秒]
(𝑡⁄103 )𝑡となる．
Libgcrypt 等他のライブラリでサポートしていないため，Ed25519ph，Ed25519ctx，
Ed448ph は計測していない．
計測用プログラム EcDsaP256.java（図 25），EcDsaP384.java（図 26），
EcDsaP521.java（図 27），EdDsaEd25519.java（図 28）および EdDsaEd448.java（図29）を作成した．

67

図 25 OpenJDK EcDsaP256 計測用プログラム EcDsaP256.java68

図 26 OpenJDK EcDsaP384 計測用プログラム EcDsaP384.java69

図 27 OpenJDK EcDsaP521 計測用プログラム EcDsaP521.java70

図 28 OpenJDK Ed25519 計測用プログラム EdDsaEd25519.java71

図 29 OpenJDK Ed448 計測用プログラム EdDsaEd448.java〈Linux〉〈Mac〉EcDsaP256.java，EcDsaP384.java，EcDsaP521.java，
EdDsaEd25519.java，EdDsaEd448.java を同一のディレクトリに配置し，そのディレク
トリ内で以下のコマンドを実行して測定用プログラムをビルドした．

72

javac -d . EcDsaP256.java
javac -d . EcDsaP384.java
javac -d . EcDsaP521.java
javac -d . EdDsaEd25519.java
javac -d . EdDsaEd448.java〈Win〉EcDsaP256.java，EcDsaP384.java，EcDsaP521.java，EdDsaEd25519.java，
EdDsaEd448.java を同一のディレクトリに配置し，そのディレクトリ内で以下のコマ
ンドを実行して測定用プログラムをビルドした．
javac -d . EcDsaP256.java
javac -d . EcDsaP384.java
javac -d . EcDsaP521.java
javac -d . EdDsaEd25519.java
javac -d . EdDsaEd448.java【計測用プログラムの実行方法】〈Linux〉〈Mac〉以下のコマンドを実行した．
java openJdkBench.EcDsaP256
java openJdkBench.EcDsaP384
java openJdkBench.EcDsaP521
java openJdkBench.EdDsaEd25519
java openJdkBench.EdDsaEd448〈Win〉以下のコマンドを実行した．
java openJdkBench.EcDsaP256
java openJdkBench.EcDsaP384
java openJdkBench.EcDsaP521
java openJdkBench.EdDsaEd25519
java openJdkBench.EdDsaEd448③ Libgcrypt【OSS の入手】〈Linux〉〈Mac〉libgpg-error 1.43 と Libgcrypt 1.9.4 を以下からダウンロード
した．
https://gnupg.org/ftp/gcrypt/libgpg-error/libgpg-error-1.43.tar.bz2

73https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.4.tar.bz2
以下の内容のコマンドを実行してライブラリをビルドし，benchlib にインストール
した．
mkdir benchlib
tar -xjf libgpg-error-1.43.tar.bz2
cd libgpg-error-1.43./configure --prefix=$PWD/../benchlib; make; make install
cd ..
tar -xjf libgcrypt-1.9.4.tar.bz2
cd libgcrypt-1.9.4./configure --prefix=$PWD/../benchlib; make; make install
cd ..
〈Win〉Libgcrypt は Visual Studio でビルドできないため，以下のコマンドでMSYS2 MinGW 64-bit のパッケージおよび依存するライブラリをインストールした．
pacman -S mingw-w64-x86_64-libgcrypt-1.9.4-1

依存するライブラリは Linux，Mac と同じバージョンであった．
【計測用プログラムの準備】
計測用プログラムは，ECDSA P-256，ECDSA P-384，ECDSA P-521，Ed25519，Ed448
について• gcry_pk_genkey 関数，gcry_sexp_find_token 関数での公開鍵取り出し，
gcry_sexp_find_token 関数での秘密鍵取り出しを一連の処理としたブロックでの鍵生成• gcry_pk_sign 関数での署名生成• gcry_pk_verify 関数での署名検証
を，それぞれ104 回実行し，それぞれの104 回分の処理時間（ナノ秒）𝑡を測定する．
𝑡を109 で割ることでナノ秒から秒に変換し，得られた秒数で104 [回]を割ることで，スループット（1 秒あたりの実行回数）を求めた．計算式は
104
1013
=
[回/秒]
(𝑡⁄109 )𝑡となる．
Libgcrypt では Ed25519ph，Ed25519ctx，Ed448ph をサポートしていないため計測していない．
libgcrypt-1.9.4/tests/benchmark.c を参考に計測用プログラム libgcrypt_benchmark.c（図 30）を作成した．

74

75

図 30 libgcrypt_benchmark.c〈Linux〉〈Mac〉libgcrypt_benchmark.c を libgcrypt-1.9.4.tar.bz2 を展開した
ディレクトリ(libgcrypt-1.9.4 ディレクトリを含むディレクトリ)に配置し，そのディレクトリ内で以下のコマンドを実行して計測用プログラムをビルドした．
gcc -o libgcrypt_benchmark libgcrypt_benchmark.c `./benchlib/bin/libgcrypt-config --cflags --libs`
export LD_LIBRARY_PATH=$PWD/benchlib/lib〈Win〉libgcrypt_benchmark.c を以下のコマンドを実行して計測用プログラムをビ
ルドした．
gcc -o libgcrypt_benchmark libgcrypt_benchmark.c `libgcrypt-config --cflags--libs`76

【計測用プログラムの実行方法】
以下のコマンドを実行した．
./libgcrypt_benchmark④ Nettle【OSS の入手】〈Linux〉〈Mac〉GMP 6.2.1 と Nettle 3.7.3 を以下からダウンロードした．
https://gmplib.org/download/gmp/gmp-6.2.1.tar.lz
https://ftp.gnu.org/gnu/nettle/nettle-3.7.3.tar.gz
以下のコマンドを実行してライブラリをビルドし，benchlib にインストールした．
mkdir benchlib
tar --lzip -xf gmp-6.2.1.tar.lz
cd gmp-6.2.1./configure --prefix=$PWD/../benchlib; make; make check && make install
cd ..
export LD_LIBRARY_PATH=$PWD/benchlib/lib
tar -xzf nettle-3.7.3.tar.gz
cd nettle-3.7.3./configure --prefix=$PWD/../benchlib; make; make install
cd ..
〈Win〉Nettle は Visual Studio でビルドできないため，以下のコマンドで MSYS2
MinGW 64-bit のパッケージおよび依存するライブラリをインストールした．
pacman -S mingw-w64-x86_64-nettle-3.7.3-1

依存するライブラリは Linux，Mac と同じバージョンであった．
【計測用プログラムの準備】
計測用プログラムは，ECDSA P-256，ECDSA P-384，ECDSA P-521，Ed25519，Ed448について• ECDSA P-256 の場合➢ ecdsa_generate_keypair 関数で鍵生成➢ sha256_init，sha256_update，sha256_digest，ecdsa_sign で署名生成➢ sha256_init，sha256_update，sha256_digest，ecdsa_verify で署名検証• ECDSA P-384，ECDSA P-521 の場合

77

➢ ecdsa_generate_keypair 関数で鍵生成➢ sha512_init，sha512_update，sha512_digest，ecdsa_sign で署名生成➢ sha512_init，sha512_update，sha512_digest，ecdsa_verify で署名検証• Ed25519 の場合➢ yarrow256_random 関数と ed25519_sha512_public_key 関数で鍵生成➢ ed25519_sha512_sign 関数で署名生成➢ ed25519_sha512_verify 関数で署名検証• Ed448 の場合➢ yarrow256_random 関数と ed448_shake256_public_key 関数で鍵生成➢ ed448_shake256_sign 関数で署名生成➢ ed448_shake256_verify 関数で署名検証をそれぞれ104 回実行し，それぞれの104 回分の処理時間（ナノ秒）𝑡を測定する．
𝑡を109 で割ることでナノ秒から秒に変換し，得られた秒数で103 [回]を割ることで，スループット（1 秒あたりの実行回数）を求めた．計算式は
104
1013
=
[回/秒]
(𝑡⁄109 )𝑡となる．
Nettle では Ed25519ph，Ed25519ctx，Ed448ph をサポートしていないため計測していない．
計測用プログラム nettle_benchmark.c（図 31），nettle_benchmark_p256.c（図32），nettle_benchmark_p384.c（図 33），nettle_benchmark_p521.c（図 34），
nettle_benchmark_ed25519.c（図 35）および nettle_benchmark_ed448.c（図 36）を
作成した．

78

図 31 nettle_benchmark.c

79

80

図 32 nettle_benchmark_p256.c

81

82

図 33 nettle_benchmark_p384.c

83

84

図 34 nettle_benchmark_p521.c85

図 35 nettle_benchmark_ed25519.c

86

図 36 nettle_benchmark_ed448.c〈Linux〉〈Mac〉nettle_benchmark.c，nettle_benchmark_p256.c，
nettle_benchmark_p384.c，nettle_benchmark_p521.c，nettle_benchmark_ed25519.c，nettle_benchmark_ed448.c を nettle-3.7.3.tar.gz を展開したディレクトリ(nettle-3.7.3 ディレクトリを含むディレクトリ)に配置し，以下のコマンドを実行して計測用プログラムをビルドした．

87

gcc -o nettle_benchmark nettle_benchmark.c nettle_benchmark_p256.c nettle_benchmark_p384.c nettle_benchmark_p521.c nettle_benchmark_ed25519.c
nettle_benchmark_ed448.c -Ibenchlib/include -Lbenchlib/lib -lhogweed -lnettle -lgmp

export LD_LIBRARY_PATH=$PWD/benchlib/lib〈Win〉nettle_benchmark.c，nettle_benchmark_p256.c，
nettle_benchmark_p384.c，nettle_benchmark_p521.c，nettle_benchmark_ed25519.c，nettle_benchmark_ed448.c を同一ディレクトリに配置し，以下のコ
マンドを実行して計測用プログラムをビルドした．
gcc -o nettle_benchmark nettle_benchmark.c nettle_benchmark_p256.c nettle_benchmark_p384.c nettle_benchmark_p521.c nettle_benchmark_ed25519.c
nettle_benchmark_ed448.c -Ibenchlib/include -Lbenchlib/lib -lhogweed -lnettle -lgmp【計測用プログラムの実行方法】
以下のコマンドを実行した．
./nettle_benchmark⑤ OpenSSL【OSS の入手】〈Win〉〈Linux〉〈Mac〉openssl 3.0.0 を以下からダウンロードした．
https://www.openssl.org/source/openssl-3.0.0.tar.gz
ダウンロード後に展開した．
Windows の場合は展開先パスにマルチバイト文字を含めないようにした．
OpenSSL に同梱されている計測用プログラムは鍵生成を測定しないため，計測用プ
ログラムを改造後にライブラリと計測用プログラムのビルドを行った．
【計測用プログラムの準備】
コマンドのソース apps/speed.c に対して図 37 の改造を行った．ソースが長いため差分のみを示す．

88

89

90

図 37 apps/speed.c に対する改造

計測用プログラムでは• EVP_PKEY_keygen 関数で鍵生成• EVP_DigestSign 関数で署名生成91• EVP_DigestVerify 関数で署名検証を，それぞれ 10 秒間繰り返して繰り返し回数𝑛を測定する．𝑛を 10 秒で割ることで，スループット（1 秒あたりの実行回数）を求めた．計算式は
𝑛
[回/秒]
10
となる．
OpenSSL は Ed25519ph，Ed25519ctx，Ed448ph をサポートしていないため計測していない．
〈Linux〉〈Mac〉改造した OpenSSL に対して，tar.gz ファイルを展開したディレク
トリ内で以下のコマンドを実行してライブラリおよび測定用プログラムをビルドした．
./Configure
makemake test
なお，システムにインストール済みの OpenSSL を破壊しないように make install は
行わない．
〈Win〉ビルドに必要なOpenSSL 推奨の perl : Strawberry Perl 5.32.1.1 64bit25
OpenSSL 推奨のアセンブラ : Netwide Assembler（NASM）2.15.0526
をインストール後，Windows の環境変数 PATH に C:\Program Files\NASM を追加した．
スタートメニューの Visual Studio 2022 ディレクトリから x64 Native Tools Command Prompt for VS 2022 を管理者権限で起動し，コマンドプロンプトで tar.gz ファ
イルを展開したディレクトリに移動した．
改造した OpenSSL に対して，以下のコマンドを実行してライブラリおよび測定用プ
ログラムをビルドした．
perl Configure VC-WIN64A
nmake
nmake test
なお，システムにインストール済みの OpenSSL を破壊しないように nmake installは行わない．

25
26

https://strawberryperl.com
https://www.nasm.us

92

【計測用プログラムの実行方法】〈Linux〉〈Mac〉以下のコマンドを実行した．
export LD_LIBRARY_PATH=$PWD./apps/openssl speed ecdsap256 ecdsap384 ecdsap521 ed25519 ed448〈Win〉以下のコマンドを実行した．
apps\openssl.exe speed ecdsap256 ecdsap384 ecdsap521 ed25519 ed448⑥ wolfSSL【OSS の入手】〈Win〉〈Linux〉〈Mac〉wolfSSL 5.0.0 を以下からダウンロードした．
https://github.com/wolfSSL/wolfssl/archive/refs/tags/v5.0.0-stable.zip
ダウンロード後に展開した．
Windows では Visual Studio を使用したビルド方法は開発元から示されているが，この方法でビルドした wolfSSL は EdDSA が含まれないことが分かった．また，MSYS2
では wolfSSL をディストリビューションで配布していないため，wolfSSL 開発者の示した MSYS2 MinGW 64-bit 上での方法でビルドすることとした．
〈Linux〉〈Mac〉〈Win〉展開したディレクトリ内で以下のコマンドを実行してライ
ブラリおよび測定用プログラムをビルドした．
mkdir ../benchlib./autogen.sh./configure --prefix=$PWD/../benchlib --enable-ecccustcurves --enableed25519 --enable-ed448
make
make install
export LD_LIBRARY_PATH=$PWD/../benchlib【計測用プログラムの準備】
wolfSSL に同梱されている計測用プログラムを利用した．
この計測用プログラムでは• ECDSA P-256，ECDSA P-384，ECDSA P-521 の場合➢ wc_ecc_make_key_ex 関数で鍵生成➢ wc_ecc_sign_hash 関数で署名生成➢ wc_ecc_verify_hash 関数で署名検証

93

•Ed25519 の場合➢ wc_ed25519_make_key 関数で鍵生成➢ wc_ed25519_sign_msg 関数で署名生成➢ wc_ed25519_verify_msg 関数で署名検証• Ed448 の場合➢ wc_curve448_make_key 関数で鍵生成➢ wc_ed448_sign_msg 関数で署名生成➢ wc_ed448_verify_msg 関数で署名検証を，それぞれ 1 秒間繰り返して繰り返し回数𝑛を測定してスループット（1 秒あたりの実行回数）を求めた．
Libgcrypt 等他のライブラリでサポートしていないため，Ed25519ph，Ed25519ctx，
Ed448ph は計測していない．
【計測用プログラムの実行方法】〈Linux〉〈Mac〉〈Win〉以下のコマンドを実行した．
./wolfcrypt/benchmark/benchmark -ecc-all -ed25519-kg -ed25519 -ed448-kg-ed4485.4.3.

性能測定結果と評価

測定結果はスループット（回/秒）で統一した．

① 鍵ペア生成
鍵ペア生成のスループット測定結果を表 10 に示す．
表 10 鍵ペア生成 スループット測定結果（回/秒）
Bouncy Castle

ECDSA P-256
ECDSA P-384
Windows ECDSA P-521
Ed25519
Ed448
ECDSA P-256
ECDSA P-384
Linux ECDSA P-521
Ed25519
Ed448
ECDSA P-256
ECDSA P-384
Mac
ECDSA P-521
Ed25519
Ed448

4566.22155.21347.79345.84424.85586.62702.71569.914492.85780.35263.22481.41402.511627.94975.1OpenJDK Libgcrypt1408.5
51.1
734.8
34.8
404.5
21.0
2132.2
75.9
769.8
59.1
1721.2
172.6
889.7
88.9
478.2
44.2
2816.9
498.3
910.7
311.2
1626.0
114.4
825.1
62.4
458.3
31.1
2631.6
465.9
874.9
294.7

94

nettle24791.9
10621.85576.731620.09272.030224.9
13615.57090.835703.3
11478.2
28981.1
13533.5
6693.2
35966.010901.0

OpenSSL3.0.0

23885.2
1003.9486.1
26747.02745.940558.6
1458.4608.436800.2
5589.325298.1
1335.2588.027178.020436.6

WolfSSL
681.9
240.9
144.8
49900.812989.2
797.7
279.2
167.6
49860.2
14574.6
849.4
272.3
151.2
54304.911809.1

ECDSA P-256 と Ed25519 の鍵ペア生成におけるスループット比較のグラフを図 38，
図 39 および図 40 に示す．

鍵ペア生成におけるECDSA P-256とEd25519のスループット比較：Windows

60000.050000.040000.030000.020000.0
10000.0

0.0
Bouncy Castle

OpenJDK

Libgcrypt

nettleECDSA P-256

Ed25519

OpenSSL3.0.0

WolfSSL

図 38 鍵ペア生成における ECDSA P-256 と Ed25519 のスループット比較：Windows

鍵ペア生成におけるECDSA P-256とEd25519のスループット比較：Linux

60000.050000.040000.030000.020000.0
10000.0
0.0
Bouncy Castle

OpenJDK

Libgcrypt

nettleECDSA P-256

Ed25519

OpenSSL3.0.0

WolfSSL

図 39 鍵ペア生成における ECDSA P-256 と Ed25519 のスループット比較：Linux95

鍵ペア生成におけるECDSA P-256とEd25519のスループット比較：Mac

60000.050000.040000.030000.020000.0
10000.0
0.0
Bouncy Castle

OpenJDK

Libgcrypt

nettleECDSA P-256

Ed25519

OpenSSL3.0.0

WolfSSL

図 40 鍵ペア生成における ECDSA P-256 と Ed25519 のスループット比較：Mac

wolfSSL の ECDSA P-256 と Ed25519 の性能差が非常に大きいが，プラットフォームによらず同じ傾向となっていることから，誤差ではないと考えられる．C 言語のwolfSSL の ECDSA P-256 が Java の OpenJDK より低いスループットとなっていることから，wolfSSL の ECDSA P-256 のスループットが C 言語実装のわりに低いと考えられる．wolfSSL の ECDSA P-256 のスループットが仮に Nettle や OpenSSL 並であれば，
Ed25519 との比率は 1～2 倍となり不自然さはなくなると思われる．
同じ方式を実装したにもかかわらず OSS によって性能にバラツキはあるが，どのプ
ラットフォームでも最も高いスループットのアルゴリズムは Ed25519 であり，これらの OSS を比較した限りでは，同程度の安全性の ECDSA P-256 に比べ，Ed25519 の鍵生成は高スループットの実装となる傾向があると言える．
ECDSA P-384，ECDSA-P521，Ed448 の鍵ペア生成におけるスループット比較のグラフを図 41，図 42 および図 43 に示す．

鍵ペア生成におけるECDSA P-384とECDSA P-521，Ed448のスループット比較：Windows

14000.012000.0
10000.0
8000.06000.04000.02000.0

0.0
Bouncy Castle

OpenJDK

Libgcrypt

ECDSA P-384

nettleECDSA P-521

OpenSSL3.0.0

WolfSSL

Ed448

図 41 鍵ペア生成における ECDSA P-384 と ECDSA P-521，Ed448 のスループット比較：
Windows96

鍵ペア生成におけるECDSA P-384とECDSA P-521，Ed448のスループット比較：Linux

20000.015000.0

10000.0
5000.0

0.0
Bouncy Castle

OpenJDK

Libgcrypt

ECDSA P-384

nettleECDSA P-521

OpenSSL3.0.0

WolfSSL

Ed448

図 42 鍵ペア生成における ECDSA P-384 と ECDSA P-521，Ed448 のスループット比較：
Linux

鍵ペア生成におけるECDSA P-384とECDSA P-521，Ed448のスループット比較：Mac

25000.020000.015000.0
10000.0
5000.0

0.0
Bouncy Castle

OpenJDK

Libgcrypt

ECDSA P-384

nettleECDSA P-521

OpenSSL3.0.0

WolfSSL

Ed448

図 43 鍵ペア生成における ECDSA P-384 と ECDSA P-521，Ed448 のスループット比較：Mac

wolfSSL と OpenSSL の ECDSA P-384，ECDSA P-521 と Ed448 の性能差が非常に大きいが，プラットフォームによらず同じ傾向となっていることから，誤差ではないと考えられる．C 言語の wolfSSL と OpenSSL の ECDSA P-384，ECDSA P-521 が Java の OpenJDKより低いか同程度のスループットとなっていることから，wolfSSL と OpenSSL の ECDSA
P-384，ECDSA P-521 のスループットが仮に Nettle 並であれば，Ed25519 との比率は同程度となり不自然さはなくなると思われる．
Mac の OpenSSL3.0.0 の Ed448 のスループットが Windows の OpenSSL3.0.0 の Ed448
もスループットに比べて 7 倍以上となっている．CPU が異なるとはいえ，同じソース
からビルドしているため，これほどの差がついたのは，アルゴリズムや実装の仕方によらない原因（例えばコンパイラの違いによる最適化）による可能性がある．
同じ方式を実装したにもかかわらず OSS によって性能にバラツキはあるが，どのプ
ラットフォームでも最も高いスループットのアルゴリズムは Ed448 であり，これらの97

OSS を比較した限りでは，低い安全性の ECDSA P-384 に比べても，Ed448 の鍵生成は同程度かやや高スループットの実装となる傾向があると言える．

② 署名生成署名生成のスループット測定結果を表 11 に示す．
表 11 署名生成スループット測定結果（回/秒）

Windows

Linux

Mac

Bouncy Castle
2331.01129.9561.2
20408.2
6024.13300.31210.7628.921739.1
6493.52604.21068.4595.9
20000.05917.2ECDSA P-256
ECDSA P-384
ECDSA P-521
Ed25519
Ed448
ECDSA P-256
ECDSA P-384
ECDSA P-521
Ed25519
Ed448
ECDSA P-256
ECDSA P-384
ECDSA P-521
Ed25519
Ed448

OpenJDK
1661.1733.1
371.3
1312.3408.2
1893.9863.6
422.1
1647.4475.3
1782.5800.0
398.6
1545.6449.6

Libgcrypt
457.7
240.8
107.8
2207.8
760.2
742.6
340.9
157.1
2528.6
823.5
432.8
226.9
106.8
2161.9781.6

nettleOpenSSL3.0.0
17197.3
43939.4
7856.71011.14055.1474.430745.1
28579.89535.62735.821508.957375.99945.11439.35235.4621.1
35597.539167.911294.6
5572.820405.744969.4
9715.11337.24910.3573.135485.029554.7
10657.820479.0

WolfSSL
1309.6460.8
280.8
44471.8
12663.3
1543.0540.1
295.1
42388.913725.5
1617.9521.8
295.4
48203.1
11403.7

ECDSA P-256 と Ed25519 の署名生成におけるスループット比較のグラフを図 44，図45 および図 46 に示す．

署名生成におけるECDSA P-256とEd25519のスループット比較：Windows

50000.040000.030000.020000.0
10000.0

0.0
Bouncy Castle

OpenJDK

Libgcrypt

nettleECDSA P-256

Ed25519

OpenSSL3.0.0

WolfSSL

図 44 署名生成における ECDSA P-256 と Ed25519 のスループット比較：Windows98署名生成におけるECDSA P-256とEd25519のスループット比較：Linux

70000.0
60000.050000.040000.030000.020000.0
10000.0

0.0
Bouncy Castle

OpenJDK

Libgcrypt

nettleECDSA P-256

Ed25519

OpenSSL3.0.0

WolfSSL

図 45 署名生成における ECDSA P-256 と Ed25519 のスループット比較：Linux

署名生成におけるECDSA P-256とEd25519のスループット比較：Mac

60000.050000.040000.030000.020000.0
10000.0
0.0
Bouncy Castle

OpenJDK

Libgcrypt

nettleECDSA P-256

Ed25519

OpenSSL3.0.0

WolfSSL

図 46 署名生成における ECDSA P-256 と Ed25519 のスループット比較：Mac

Bouncy Castle と wolfSSL の ECDSA P-256 と Ed25519 の性能差が非常に大きいが，プラットフォームによらず同じ傾向となっていることから，誤差ではないと考えられる．C 言語の wolfSSL の ECDSA P-256 が Java の OpenJDK より低いスループットとなっていることから，C 言語実装の wolfSSL の ECDSA P-256 のスループットが低いと考えられる．wolfSSL の ECDSA P-256 のスループットが仮に OpenSSL 並であれば，同程度のスループットとなり不自然さはなくなると思われる．
OpenJDK と OpenSSL ではどのプラットフォームでも ECDSA P-256 が高いスループッ
トだった．一方で，それ以外の 4 つの OSS では Ed25519 が高スループットであり，OSS
によって分かれた形となった．特に OpsnSSL の ECDSA P-256 と wolfSSL の Ed25519 はほぼ同じ程度で高いスループットとなっている．
同じ方式を実装したにもかかわらず OSS によって性能にバラツキはあるが，高速な実装をすれば ECDSA P-256 と Ed25519 は同程度のスループットとなるが，アルゴリズ
ムを素直に実装すれば，同程度の安全性の ECDSA P-256 に比べ，Ed25519 の署名生成は高スループットの実装となる傾向があると言える．

99

ECDSA P-384，ECDSA P-521 と Ed448 の署名生成におけるスループット比較のグラフ
を図 47，図 48 および図 49 に示す．

署名生成におけるECDSA P-384とECDSA P-521，Ed448のスループット比較：Windows

14000.012000.0
10000.0
8000.06000.04000.02000.0

0.0
Bouncy Castle

OpenJDK

Libgcrypt

ECDSA P-384

nettleECDSA P-521

OpenSSL3.0.0

WolfSSL

Ed448

図 47 署名生成における ECDSA P-384 と ECDSA P-521，Ed448 のスループット比較：Windows

署名生成におけるECDSA P-384とECDSA P-521，Ed448のスループット比較：Linux

15000.0

10000.0

5000.0

0.0
Bouncy Castle

OpenJDK

Libgcrypt

ECDSA P-384

nettleECDSA P-521

OpenSSL3.0.0

WolfSSL

Ed448

図 48 署名生成における ECDSA P-384 と ECDSA P-521，Ed448 のスループット比較：Linux100

署名生成におけるECDSA P-384とECDSA P-521，Ed448のスループット比較：Mac

25000.020000.015000.0
10000.0
5000.0

0.0
Bouncy Castle

OpenJDK

Libgcrypt

ECDSA P-384

nettleECDSA P-521

OpenSSL3.0.0

WolfSSL

Ed448

図 49 署名生成における ECDSA P-384 と ECDSA P-521，Ed448 のスループット比較：Mac

Bouncy Castle，wolfSSL の ECDSA P-384，ECDSA P-521 と Ed448 の性能差が非常に大きいが，プラットフォームによらず同じ傾向となっていることから，誤差ではないと考えられる．
Mac の OpenSSL3.0.0 の Ed448 のスループットが Windows の OpenSSL3.0.0 の Ed448
もスループットに比べて 7 倍以上となっている．CPU が異なるとはいえ，同じソース
からビルドしているにもかかわらず，これほどの差がついたのは，アルゴリズムや実装の仕方によらない原因（例えばコンパイラの違いによる最適化の違い）による可能性がある．
C 言語の wolfSSL の ECDSA P-384，ECDSA P-521 が Java の OpenJDK より低いスルー
プットとなっていることから，C 言語実装の wolfSSL の ECDSA P-384，ECDSA P-521 のスループットが低いと考えられる．wolfSSL の ECDSA P-384，ECDSA P-521 のスルー
プットが仮に Nettle 並であれば，比率は 1～2 倍程度となり不自然さはなくなると思われる．
同じ方式を実装したにもかかわらず OSS によって性能にバラツキはあるが，どのプ
ラットフォームでも最も高いスループットのアルゴリズムは Ed448 であり，これらのOSS を比較した限りでは，低い安全性の ECDSA P-384 に比べても，Ed448 の署名生成は高スループットの実装となる傾向があると言える．

③ 署名検証
署名検証のスループット測定結果を表 12 に示す．

101

表 12 署名検証スループット測定結果（回/秒）

Windows

Linux

Mac

Bouncy Castle
4201.71329.8639.87246.41919.43937.01550.4741.3
7518.82375.33144.71506.0698.8
6622.52036.7ECDSA P-256
ECDSA P-384
ECDSA P-521
Ed25519
Ed448
ECDSA P-256
ECDSA P-384
ECDSA P-521
Ed25519
Ed448
ECDSA P-256
ECDSA P-384
ECDSA P-521
Ed25519
Ed448

OpenJDK
891.3
399.4
202.6
1293.7427.0
1065.0464.0
233.6
1584.8486.6
1006.0433.7
220.1
1483.7455.2

Libgcrypt
408.2
212.4
92.9
1223.6
423.7
659.6
301.3
134.8
1358.5
450.9
393.5
202.3
92.7
1196.5428.0

nettleOpenSSL3.0.0
5678.917006.0
2621.1
1200.81311.6593.1
8867.39995.12719.42048.17110.8
19853.73152.91740.91741.0762.510797.912043.93510.45387.56541.3
18093.73073.81606.81592.8726.1
10074.1
10811.03242.56800.2

WolfSSL1884.1706.1
431.4
18295.94644.72234.6747.9
496.8
20916.85120.12375.6804.9
458.7
18492.3
3788.6ECDSA P-256 と Ed25519 の署名検証におけるスループット比較のグラフを図 50，図51 および図 52 に示す．

署名検証におけるECDSA P-256とEd25519のスループット比較：Windows

20000.015000.0
10000.0
5000.0

0.0
Bouncy Castle

OpenJDK

Libgcrypt

nettleECDSA P-256

Ed25519

OpenSSL3.0.0

WolfSSL

図 50 署名検証における ECDSA P-256 と Ed25519 のスループット比較：Windows

署名検証におけるECDSA P-256とEd25519のスループット比較：Linux

25000.020000.015000.0
10000.0
5000.0

0.0
Bouncy Castle

OpenJDK

Libgcrypt

nettleECDSA P-256

Ed25519

OpenSSL3.0.0

WolfSSL

図 51 署名検証における ECDSA P-256 と Ed25519 のスループット比較：Linux102

署名検証におけるECDSA P-256とEd25519のスループット比較：Mac

20000.015000.0

10000.0
5000.0

0.0
Bouncy Castle

OpenJDK

Libgcrypt

nettleECDSA P-256

Ed25519

OpenSSL3.0.0

WolfSSL

図 52 署名検証における ECDSA P-256 と Ed25519 のスループット比較：Mac

wolfSSL の ECDSA P-256 と Ed25519 の性能差が非常に大きいが，プラットフォームによらず同じ傾向となっていることから，誤差ではないと考えられる．C 言語のwolfSSL の ECDSA P-256 が Java の Bouncy Castle より低いスループットとなっていることから，C 言語実装の wolfSSL の ECDSA P-256 のスループットが低いと考えられる．wolfSSL の ECDSA P-256 のスループットが仮に OpenSSL 並であれば，同程度のス
ループットとなり不自然さはなくなると思われる．
OpenSSL では ECDSA P-256 が高いスループットだった．一方で，それ以外の 5 つのOSS では Ed25519 が高スループットであり，OSS によって分かれた形となった．特にOpsnSSL の ECDSA P-256 と wolfSSL の Ed25519 はほぼ同じ程度で高いスループットとなっている．
同じ方式を実装したにもかかわらず OSS によって性能にバラツキはあるが，高速な実装をすれば ECDSA P-256 と Ed25519 は同程度のスループットとなるが，アルゴリズ
ムを素直に実装すれば，同程度の安全性の ECDSA P-256 に比べ，Ed25519 の署名生成は高スループットの実装となる傾向があると言える．
ECDSA P-384，ECDSA-P521，Ed448 の署名検証におけるスループット比較のグラフを
図 53，図 54 および図 55 に示す．

103

署名検証におけるECDSA P-384とECDSA P-521，Ed448のスループット比較：Windows

5000.04000.03000.02000.01000.0

0.0
Bouncy Castle

OpenJDK

Libgcrypt

ECDSA P-384

nettleECDSA P-521

OpenSSL3.0.0

WolfSSL

Ed448

図 53 署名検証における ECDSA P-384 と ECDSA P-521，Ed448 のスループット比較：Windows

署名検証におけるECDSA P-384とECDSA P-521，Ed448のスループット比較：Linux

6000.05000.04000.03000.02000.01000.0
0.0
Bouncy Castle

OpenJDK

Libgcrypt

ECDSA P-384

nettleECDSA P-521

OpenSSL3.0.0

WolfSSL

Ed448

図 54 署名検証における ECDSA P-384 と ECDSA P-521，Ed448 のスループット比較：Linux

署名検証におけるECDSA P-384とECDSA P-521，Ed448のスループット比較：Mac

8000.06000.04000.02000.0

0.0
Bouncy Castle

OpenJDK

Libgcrypt

ECDSA P-384

nettleECDSA P-521

OpenSSL3.0.0

WolfSSL

Ed448

図 55 署名検証における ECDSA P-384 と ECDSA P-521，Ed448 のスループット比較：Mac104

wolfSSL の ECDSA P-384，ECDSA P-521 と Ed448 の性能差が非常に大きいが，プラッ
トフォームによらず同じ傾向となっていることから，誤差ではないと考えられる．
Mac の OpenSSL3.0.0 の Ed448 のスループットが Windows の OpenSSL3.0.0 の Ed448 もスループットに比べて 3.3 倍以上となっている．CPU が異なるとはいえ，同じソース
からビルドしているにもかかわらず，これほどの差がついたのは，アルゴリズムや実装の仕方によらない原因（例えばコンパイラの違いによる最適化の違い）による可能性がある．
C 言語の wolfSSL の ECDSA P-384，ECDSA P-521 が Java の Bouncy Castle より低い
スループットとなっていることから，C 言語実装の wolfSSL の ECDSA P-384，ECDSA P521 のスループットが低いと考えられる．wolfSSL の ECDSA P-384，ECDSA P-521 のス
ループットが仮に Nettle 並であれば，比率は 1～2 倍程度となり不自然さはなくなると思われる．
同じ方式を実装したにもかかわらず OSS によって性能にバラツキはあるが，どのプ
ラットフォームや OSS でも高いスループットのアルゴリズムは Ed448 であり，これらの OSS を比較した限りでは，低い安全性の ECDSA P-384 に比べても，Ed448 の署名生成は高スループットの実装となる傾向があると言える．

105

6. EdDSA に関する実装評価まとめ
本調査では，RFC8032 [2]に記載された EdDSA のアルゴリズムとしての特徴を確認し，世間での採用の動向を調査し，実際の性能測定し，実装性能を評価した．
EdDSA のアルゴリズムとしての特徴は以下のようであった．
• 一般的な EdDSA と比較して，推奨パラメータが固定であることや推奨される座標系の特性により乗法逆元の処理が不要となり処理が単純化されているため高速化しやすい．
• 一般的な EdDSA と比較して，条件分岐等を考慮する必要がないため実装がしや
すい．
• 実装するアルゴリズムが 1 つで条件分岐等を考慮する必要がなく分岐がないため，SCA 対策として有用である．
つまり，RFC8032 [2]で詳細について触れられていない有限体の演算を除くと，推奨される処理手順のみでも安全性や性能，実装コストの抑制がある程度，担保される．
また，RFC8032 [2]として標準化された EdDSA は，Draft 版を含めると 41 件の標準が採用し，少なくとも 20 件の OSS の暗号ライブラリが採用していた．2017 年のアルゴリズム発表から 4 年が経過して，署名方式として定着しつつあることが分かった．
さらに，2 件の Draft 版の標準で参照していた FIPS Pub 186-5 (Draft) [12]にも同じ
アルゴリズムが含まれており，RFC8032 [2]と FIPS Pub 186-5 (Draft) [12]に共通して含まれる方式として今後もさらに利用が広がると予想される．
ただし，Ed448 は採用する標準や OSS の暗号ライブラリが Ed25519 に比べて少なかった．
調査した標準 46 件のうち，Ed25519 を採用していたものが 46 件，Ed448 を採用していたものが 28 件であり，EdDSA を採用している OSS の暗号ライブラリ 20 件のうち，20 件すべてが Ed25519 を使用している一方で，Ed448 を採用していたのは 8 件であった．
OSS の暗号ライブラリでの実装について品質という観点から，脆弱性に関する報告についても調査すると 2 件が見つかった．
OSS の暗号ライブラリの第三者による実装性能の測定値から• Ed25519 は ECDSA P-256 と同等の安全性でありながら高速• Ed448 は ECDSA P-384 より高い安全性でありながら高速という傾向が読み取れた．
C 言語の 4 個，Java の 2 個の OSS の暗号ライブラリを，Windows，Linux，Mac の 3
つの OS 上でそれぞれ動かした計 18 個の環境で，実際に性能測定をしたところ，各環境の結果は以下のようになった．
• Ed255519➢ 鍵ペア生成

106



•

17 環境で ECDSA P-256 より高スループットだった．
1 環境では ECDSA P-256 より低スループットだったが 50%未満の極端な差はなかった．
➢ 署名生成 12 環境で ECDSA P-256 より高スループットだった．
6 環境では ECDSA P-256 より低スループットだったが 50%未満の極端な差はなかった．
➢ 署名検証 15 環境で ECDSA P-256 より高スループットだった．
3 環境では ECDSA P-256 より低スループットだったが 50%未満の極端な差はなかった．
Ed448➢ 鍵ペア生成 15 環境で ECDSA P-384 より高スループットだった．
3 環境では ECDSA P-384 より低スループットだったが 50%未満の極端な差はなかった．
18 環境で ECDSA P-521 より高スループットだった．
➢ 署名生成 15 環境で ECDSA P-384 より高スループットだった．
3 環境では ECDSA P-384 より低スループットだったが 50%未満の極端な差はなかった．
18 環境で ECDSA P-521 より高スループットだった．
➢ 署名検証 15 環境で ECDSA P-384 より高スループットだった．
3 環境では ECDSA P-384 より低スループットだったが 50%未満の極端な差はなかった．
18 環境で ECDSA P-521 より高スループットだった．

以上の結果から，今回の測定した範囲では，Ed25519 は ECDSA P-256 と同等の安全性でありながら高速であると評価でき，Ed448 は ECDSA P-384 より高い安全性でありながら同等または高速であると評価できる．また，この結果は第三者の測定結果の傾向とも一致する．
以上の調査結果から，EdDSA は，方式そのものに安全性担保，高速化，実装がしやすい特性があると評価でき，実際に OSS で実装された暗号ライブラリの性能は，同程度の安全性の ECDSA や高い安全性の ECDSA と比べても遜色のないものであった．実装
された OSS の品質，高速化技法は洗練されているとは言い切れないが，歴史のある
ECDSA と比べても性能で劣ることはないと考えられる．

107

7. 参考文献[1] Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schewabe , Bo-Yin
Yang, “High-speed high-security signatures,” 2011.
[2] Internet Research Task Force (IRTF), “RFC8032 Edwards-Curve Digital
Signature Algorithm (EdDSA),” 2017.
[3] Harold M. Edwards, “A normal form for elliptic curves,” In Bulletinof the American Mathematical Society, 2007.
[4] Daniel J. Bernstein , Tanja Lange, “Faster addition and doubling on
elliptic curves,” 2007.
[5] Claus P. Schnorr, “Efficient Identification and Signatures for Smart
Cards,” 1990.
[6] 新保 淳, 岡田 光司 , 丹羽 朗人, “ECDSA 評価報告書,” 2001.
[7] Internet Research Task Force (IRTF), “RFC7748 Elliptic Curves for Security,” 2016.
[8] 藤﨑 英一郎, “ディジタル署名 EdDSA の構成の安全性に関する調査および評
価,” 2020.
[9] 安田 雅哉, “ディジタル署名 EdDSA で使われている曲線の安全性に関する調査及び評価,” 2020.
[10] Steven D. Galbraith, “CRYPTREC Review of EdDSA,” 2020.
[11] John M. Pollard, “Monte carlo methods for index computation (mod p),”Mathematics of computation, 第 32 巻 143 号, p. 918–924, 7 1978.
[12] National Institute of Standards and Technology, “FIPS Pub 186-5(Draft) Digital Signature Standard (DSS),” 2019.
[13] National Institute of Standards and Technology, “SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions FIPS PUB 202,”2015.
[14] Internet Engineering Task Force (IETF), “RFC6234 US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF),” 2011.
[15] Huseyin Hisil, Kenneth Koon-Ho Wong, Gary Carter , Ed Dawson, “Twisted
Edwards Curves Revisited,” Springer-Verlag, 2008.
[16] VAMPIRE lab, “SUPERCOP,”https://bench.cr.yp.to/supercop.html.

108