web-dev-qa-db-ja.com

Diffie-Hellman鍵交換では、共有ベース鍵「p」はどのように知られ、AとBはEveからどのように保護されますか?

私はHellman、Diffie、Merkleの鍵交換設計に頭を抱えようとしていますが、それについて Wiki記事 を読んだ後、一般に知られている要因( 'p' 、私は思う)になるのですか?

最初の素人の説明では、彼らは最初にそれを次のように説明します:「黄色のペイントはすでにアリスとボブによって合意されていることに注意してください」。しかし、交換の元の説明は次のとおりです。「Diffie-Hellman鍵交換方式では、相互に事前の知識がない2つの当事者が共有秘密鍵を共同で確立できます。」

共有ベースの「ペイント」(私は一般に知られている素数であると理解しています)はどこから来たのですか?アルゴリズム自体に組み込まれていますか?だれかがそれを知っていると仮定すると、中間者攻撃が両方の接続を独自のキーで乗っ取り、攻撃者の秘密キーに基づいて2つの暗号化キー間の「変換」サービスを提供することの問題はなぜですか?

5
Alain

コツは、アリスとボブがnon-secret情報を自由に共有できることです。彼らは黄色が彼らのベースカラーになることに同意することができます、そして、彼女がこれを見つけたとしてもそれはイブを全く助けません。

イブがボブに送った緑色のペイントアリスをインターセプトすると、彼女はそれが黄色と他の色で作られたことがわかりますが、他の色を理解することは、これだけの情報を使っても実行するのが困難です。

そして、はい、中間者が問題です。中間者とは、具体的には、通信の鍵交換部分に対する攻撃です。 Diffie-Hellmanはそれを助けません。

6
Graham Hill

共有ベースの「ペイント」(私は一般に知られている素数であると理解しています)はどこから来たのですか?アルゴリズム自体に組み込まれていますか?

プレーンテキストで送信できます

だれかがそれを知っていると仮定すると、中間者攻撃が両方の接続を独自のキーで乗っ取り、攻撃者の秘密キーに基づいて2つの暗号化キー間の「変換」サービスを提供することの問題はなぜですか?

これは認証の問題であり、D-Hキー交換によって解決されるものではありません。たとえば、D-Hを暗号化された信頼の連鎖と組み合わせる必要があります(たとえば、過去の通信から、いくつかの信頼された公開鍵サーバーの確認、または認証局の使用)。

wikipedia から:

元の説明では、Diffie-Hellman交換自体は通信相手の認証を提供していないため、中間者攻撃に対して脆弱です。真ん中の人は2つの異なるDiffie–Hellman鍵交換を確立する可能性があります。1つはアリスともう1つはボブであり、アリスからボブになりすましている、またはその逆の場合、攻撃者は解読(および読み取りまたは保存)してから再暗号化できます。それらの間で渡されるメッセージ。この種の攻撃を防ぐには、一般に通信相手を相互に認証する方法が必要です。これらのタイプの攻撃を回避するために、STSなどのDiffie-Hellmanのバリアントを代わりに使用できます。

5
dr jimbob

Raw Diffie-Hellmanは、同じ地下鉄駅にいるが線路の反対側にいる2人の間の通信を可能にするためのものです。彼らはお互いを見ることができ、お互いに何かを叫ぶことができますが、駅の誰もがそれらを見て、聞くことができます。彼らは自分が聞いたことが実際に他の人が言ったことを知っています。彼らがお互いに送信するメッセージは、気づかずに変更することはできません(たとえば、電車が通過したときや、バイオリンを使った凶悪犯がやってきたとき、通信が妨害される可能性がありますが、それは敵の力の範囲です)。

これらの条件下では、Diffie-Hellman鍵交換から始めて、安全な通信が可能です。関係者の1人は、係数pおよびジェネレーターg;を叫びます。または、同等に、使用する 楕円曲線 の定義。 "well-known"グループパラメータ を使用できます。同じグループが誰でも何度も使用されても問題ないからです。

そして そのためのアプリがあります

1
Thomas Pornin