ECDSA対ECDH対Ed25519対Curve25519
OpenSSHで利用可能なECCアルゴリズム（ECDH、ECDSA、Ed25519、Curve25519）の中で、最高レベルのセキュリティを提供します。そして（理想的には）なぜですか？
SSHでは、2アルゴリズムが使用されます：鍵交換アルゴリズム（Diffie-HellmanまたはECDHと呼ばれる楕円曲線バリアント）と署名アルゴリズム。鍵交換により、そのセッションのデータを暗号化するために使用される秘密鍵が生成されます。署名は、クライアントが適切なサーバーと通信できることを確認できるようにするためのものです（サーバーが鍵ベースのクライアント認証を実施する場合は、クライアントが計算した別の署名を使用できます）。
ECDHはcurve;を使用します。ほとんどのソフトウェアは標準のNIST曲線P-256を使用します。 Curve25519は別の曲線で、「販売ピッチ」はP-256よりも速く、強くはありません。パフォーマンスの違いは、人間の観点から見ると非常に小さいものです。ここでは、小さなPCでのミリ秒未満の計算について話していますが、これはSSHセッションごとに1回だけ発生します。あなたはそれに気づかないでしょう。どちらの曲線も、他の曲線よりも「強い」とは言えず、実際には（どちらも「破壊できない」領域ではかなり遠い）、学術的にも（どちらも「128ビットセキュリティレベル」にある）とは言えません。
ECDHが鍵交換に使用される場合でも、ほとんどのSSHサーバーとクライアントは、署名にDSAまたはRSA鍵を使用します。楕円曲線に基づく署名アルゴリズムが必要な場合は、ECDSAまたはEd25519です。曲線方程式の正確な定義によるいくつかの技術的な理由により、P-256の場合はECDSA、Curve25519の場合はEd25519です。繰り返しになりますが、どちらも強力ではありません。速度の差は非常に小さく、人間のユーザーが検出することはできません。ただし、ほとんどのブラウザー（FirefoxやChromeを含む）はECDHをサポートしていません（dhも）。
Ed25519ははるかに新しいものであり、それほど普及していないため、P-256を使用すると、現時点で相互運用性が向上するはずです。ただし、特定のサーバーを構成し、自分のマシンからアクセスしたい場合、相互運用性はそれほど重要ではありません。クライアントソフトウェアとサーバーソフトウェアの両方を制御します。
したがって、基本的には、選択は審美的なもの、つまり完全にあなた次第であり、合理的な理由はありません。とにかく、セキュリティの問題はその選択によって引き起こされることはありません。暗号化アルゴリズムはシステム全体の最も強力な部分であり、最も弱い部分ではありません。
Ed25519の概要 から、速度のメリットとセキュリティのメリットがあります。より興味深いセキュリティ上の利点の1つは、いくつかのサイドチャネル攻撃の影響を受けないことです。
- 秘密の配列インデックスはありません。ソフトウェアは、RAMの秘密アドレスからデータを読み書きすることはありません。アドレスのパターンは完全に予測可能です。したがって、ソフトウェアは、CPUキャッシュを介したアドレスのリークに依存するキャッシュタイミング攻撃、ハイパースレッディング攻撃、およびその他のサイドチャネル攻撃の影響を受けません。
- 秘密のブランチ条件はありません。ソフトウェアは、秘密データに基づいて条件付き分岐を実行することはありません。ジャンプのパターンは完全に予測可能です。したがって、ソフトウェアは、分岐予測ユニットを介した情報の漏洩に依存するサイドチャネル攻撃の影響を受けません。
比較のために、さまざまなアルゴリズムで実際のキャッシュタイミング攻撃がいくつか示されています。 http://en.wikipedia.org/wiki/Timing_attack
Curve25519 IS実際にはNIST曲線よりも安全であるという印象を受けました。曲線の形状がさまざまなサイドチャネル攻撃や実装の失敗に影響されにくいためです。参照してください。 http://safecurves.cr.yp.to
Ed25519には、鍵合意に署名するために同じ鍵を使用できるという利点があります（通常、これは行いません）。私は、これがエドワーズ曲線であるという特性であるかどうかを言うのに十分なほど数学に精通していませんが、主要な合意のためにモンゴメリ座標系（事実上Curve25519に変換）に変換されていることは知っています... Ed25519の方が多い曲線よりも、覚えておく価値のあるもの（ハッシュなど）の中で特に確定的なキー生成を指定します。これは、相互運用性を維持するために別の方法で処理する必要があるため、DJB実装については苛立たしいことです。
これまで直接回答がなかったのは、あなたの質問が、いくつかの多かれ少なかれ関連のない名前を、それらがお互いに同等の代替物であるかのように混合することです。
ECDHおよびECDSAは、暗号化方式の単なる名前です。
[〜＃〜] ecdh [〜＃〜]は、2つのパーティが安全でない通信チャネルを介して安全な鍵をネゴシエートするために使用できる鍵交換方法です。これは[〜＃〜] dh [〜＃〜]（Diffie-Hellman）鍵交換方式のバリエーションです。 ECDHはElliptic-curve Diffie–Hellmanの略です。しかし、ECDHは単なる方法です。つまり、ECDHを1つの特定の楕円曲線で使用するだけでなく、さまざまな楕円曲線で使用できます。
[〜＃〜] ecdsa [〜＃〜]は、データに変更を加えると署名の検証が失敗するような方法でデータに署名するために使用できる署名アルゴリズムです。しかし、攻撃者はそのような変更の後、データに正しく再署名することはできません。 [〜＃〜] dsa [〜＃〜]（デジタル署名アルゴリズム）のバリエーションです。 ECDSAはElliptic Curve Digital Signature Algorithmの略です。また、ECDSAは、異なる楕円曲線で使用できる方法のみを説明しています。
したがって、ECDHとECDSAのセキュリティは、次の2つの要素に依存します。
- メソッド自体はどのくらい安全ですか？メソッドが安全でない場合、Wordの最良の曲線はそれを変更しません。
- 使用されている曲線はどの程度安全ですか？曲線が安全でない場合、方法が理論的に安全であれば、曲線は役割を果たしません。
Curve25519は、特定の楕円曲線の名前です。その他の曲線は、Curve448、P-256、P-384、およびP-521と呼ばれます。
Ed25519は、EdDSAの具体的なバリエーションの名前です。 SHA-512およびCurve25519を使用してEdDSAを実行する場合、このバリエーションはEd25519。 EdDSAは、ECDSAと同様に署名アルゴリズムです。
したがって、特定の曲線に言及せずに、実装が鍵交換またはECDSAにECDHを使用してデータに署名することだけを言っている場合、通常はNIST曲線（P-256、P-384、またはP-512）を使用していると想定できます。しかし、実装では実際に常に使用される曲線に明示的に名前を付ける必要があります。
セキュリティに関するあなたの質問に答える：ECDHとECDSAは、概念的に安全な鍵交換と署名の方法であることがほとんど証明されています。したがって、ECDHとECDSAのセキュリティは、だれかが一般的に楕円暗号を解く方法を見つけるかどうかという事実にかなり依存します。 （ほとんど可能性がありますが不可能ではない）または使用されている曲線内に欠陥を見つける（可能性が高い）。
一部の人々がNIST標準曲線よりもCurve25519を好む理由は、NISTが既存の代替案を優先してこれらの曲線を選択した理由を明確に文書化していないためです。一般的なステートメント「カーブは見かけ上、最適なセキュリティと実装効率のために選択されました」は、マーケティングボルダーダッシュのように聞こえ、暗号の専門家を納得させません。
NISTはまた、2006年に乱数ジェネレーターベースの楕円曲線暗号（Dual_EC_DRB）を標準化し、ニューヨークの時代は（=エドワードスノーデンによってリークされたメモを確認した後）、NSA NISTに影響を与えたこの特定の乱数ジェネレーターを標準化します。そのジェネレーターに大きな弱点が発見されました。これは、NSAによって配置された意図的なバックドアであり、それに基づいてTLS暗号化を破ることができると考えられていますANSIは、Dual_EC_DRBが最初に提出されたときに明らかに弱点を発見しましたが、それを回避する方法を知っていても、アルゴリズムを改善したり、弱点を公表したりしなかったため、許可されていなかったと考えられています（弱点が公表されました。弱点が公に知られるようになると、規格は2014年に撤回されました。
もちろん、その背景知識があるので、人々はおそらく、神秘的なNIST曲線パラメーターのソースがNSAである可能性があるのではないかと考え始めました。しかし、NSAはそれらについて知っている可能性があるため、これらの曲線に基づいて暗号を解読できる可能性があります。その主張の証拠はなく、推定証拠もありませんが、確かに可能であり、より現実的なようですだから、人々はこれらの曲線への信頼を失い、可能性が非常に低い代替手段に切り替えたのです。
Curve25519は、ドイツ系アメリカ人の数学者であり、暗号学者であるDaniel J. Bernsteinによって2005年に公開されました。DanielJ. Bernsteinは、有名なSalsa20ストリーム暗号および現在広く使用されているChaCha20バリアントも設計しました。彼はまた、Poly1305メッセージ認証を発明しました。 Googleは、Poly1305と組み合わせたChaCha20は、アルゴリズムが壊れているためにRC4を削除する必要があった後、TLSで使用する安全な代替手段であると判断しました。 AESブロックチッパーを使用する場合よりもはるかに少ない計算能力で済みます（バッテリーランタイムを節約できるため、モバイルデバイスに非常に役立ちます）が、同等のセキュリティを提供すると考えられています。 ChaCha20/Poly1305はRFC 7905で標準化されており、現在、TLSクライアント/サーバー通信で今日広く使用されています。したがって、バーンスタインがNSAスパイである可能性が非常に低い場合、今日よく使用されているTLSはおそらくデータを秘密の目から保護するのにおそらく役に立たないでしょう。サービス。