問題タブ [diffie-hellman]

OpenSSL 1.0.0d を使用して ECDH キー交換 GOST 34.10-2001 を実装しようとしています。次のようにgostエンジンをロードしています：

この時点で、GOST エンジンがロードされ、正常に動作します (そう思います)。ハッシュアルゴリズムと暗号化アルゴリズムを使用していくつかのテストを行いました。

しかし、ECDH (相手側の公開鍵をインポートして共有鍵を生成する) を実装しようとすると、不適切な結果が得られます (相手側と共有鍵が異なります)。

a、b、p、q、x、y パラメータをチェックし、コード フローをチェックしましたが、何が問題なのかわかりません。

1 つある: VKO 34.10-2001 アルゴリズムは openssl\engines\ccgost\gost2001_keyx.c (関数 VKO_compute_key) に実装されていますが、汎用関数 ECDH_compute_key を呼び出すと、VKO_compute_key につながりません (int3 を設定してこれを確認しました)。 VKO_compute_key の先頭)。

私は何かを誤解しましたか？または、誰かがopensslからgostエンジンを使用して共有キーを生成する例を示すことができますか?

弾力のある城の .net ライブラリを使用して Diffie-Hellman 鍵交換を実行しようとしていますが、DHParams オブジェクトを生成するときに問題が発生しています。

私のソリューションには、接続するクライアントごとに個別の DH キー/ペアを生成する中央機関が含まれます。アイデアは、接続するクライアントごとに個別の DH キー アグリーメントを保持するというものです。次に、クライアントが dh 鍵合意を計算するクライアントに p,g 値を送信します。クライアントごとに異なる p,g 値を生成したいと考えています。そのために BigInteger を使用していますが、いくつかの問題が発生しています。

新しい DHParameters オブジェクトを作成しようとすると、768 以外のビット長を使用するたびに次の例外がスローされます。

それが問題かどうかはわかりませんが、確実に BigInteger コンストラクターでさまざまな値を試してみました。

これが私のコードです：

問題は、768 ビットの素数を生成するのに時間がかかりすぎることです。他のプロセスが実行されていないデュアル コア 2.1Ghz プロセッサでは、5 秒以上かかります。これは、接続を開始する各クライアントで発生するペナルティが大きすぎます。BigInteger のビット長を小さくしたいと思います。

私はおそらくこれを完全に間違っています.弾む城でDHを行う方法に関するドキュメントはほとんどなく、テスト/例は私の使用例と一致しません. 事前に生成された p、g 値は必要ありません。

EDIT 768 ビット長でも時々エラーが発生するようです。マシンを再起動した後、1024 以外のビット長を動作させることができず、それでも約 80% の時間しか使用できませんでした。私は何か間違ったことをしていると思います。

Zend_Crypt_DiffieHellmanクラスの使用例はありますか？ZendFramework上のPHPサーバーと安全に通信するデスクトップアプリケーションを作成しようとしています。2つのパーティ間で共有キーを確立する方法を理解するのに苦労しています。自分の素数のセットを取得する必要がありますか？

これを使用して共有キーを取得する方法の例をいただければ幸いです。

私の本当の質問は、素数とそのジェネレーターを取得する方法だと思います。

RFC3526 では、素数は 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 } の形式で表されます。

「[2^1406 pi]」の部分の意味を知りたい

THKS

SSHプロトコルのnode.js実装用にdiffie-hellman-group1-sha1キー交換を実装しようとしています。

これには組み込みの暗号モジュールを使用したいと思います。私のコード：

しかし、node.jsはそれを実行できません。次のエラーがスローされます：「エラー：初期化されていません」

誰かが何が悪いのか知っていますか？

そのため、C# クライアントを既存のサーバー テクノロジと連携させるプロジェクトに取り組んでいます。要件の 1 つは、Diffie-Hellman を使用した鍵交換です。

公開 P と G はわかっているので、サーバーに送信する 1024 ビットの公開鍵を生成する必要があります。

以下は、OpenSSL を使用した C++ のサーバー側で使用されます。現在、P/Invoke 経由で呼び出されるネイティブ DLL で同じコードを使用していますが、同様に機能します。可能であれば、ネイティブ DLL の依存関係を排除したいと考えています。

これにより、1024 ビットの公開鍵が生成されます。

BouncyCastle で DH クラスを使用してみましたが、何らかの理由で 1024 ビット キーを取得できず、代わりに 960 ビット キーを取得したいと考えています。たぶん、自分が何をしているのかよくわかっていないからです。クラスの使用方法に関する実際の説明はあまり見つかりませんでした。

BouncyCastle DH クラスを使用して、上記の OpenSSL DH コードと同じように動作させることはできますか? そうでない場合、より適切に機能する別の C# 実装はありますか?

Diffie-Hellman Key ExchangeでYouTubeビデオを見た後、JavaScript（Atwoodの法則）での実装を試してみたかったのです。

Node.jsで次のルールを使用して暗号をスケッチしました。

• ステップ1：クライアントとサーバーが共有キーについて合意します。

  • クライアントとサーバーは512ビットのプライム公開鍵pKで開始します

  • クライアントは512ビットのプライム秘密鍵kCを生成し、powMod（3、kC、pK）を送信します

  • サーバーは512ビットのプライム秘密鍵kSを生成し、powMod（3、kS、pK）を送信します

  • クライアントとサーバーは、共有キーとしてpowMod（response、privatekey、pK）を使用します

• ステップ2：コミュニケーション

  • クライアントがデータを送信する前に、Stanford Javascript Crypto Library（256ビットAES、HMAC認証、PBKDF2パスワード強化、およびCCM認証付き暗号化）を使用して共有キーで暗号化されます。

  • サーバーが共有キーを使用してデータを復号化すると、サーバーは新しい512ビットのプライム秘密キーを生成し、SJCL暗号化応答として送信します。

  • クライアントとサーバーは、powMod（3、prevSharedKey、newPrivKey）を使用して新しい共有キーに切り替えます

今、私はいくつかの質問があります。

このようなシステムは、HTTPSや他のアルゴリズムと比較してどの程度安全ですか？そのようなシステムの弱点は何ですか？

セキュリティ/実用性の観点から、セキュリティを強化するために1024ビットキーを使用する方が良いでしょうか？HMAC / PBKDF2 / CCMオプションはやり過ぎですか？共有キーを変調する価値はありますか？読んでくれてありがとう！

アリスとボブがDiffie-Hellman鍵交換を使用して互いにメッセージを送信するプロジェクトを行っています。私にループを投げかけているのは、彼らが使用している証明書をこれに組み込んで、彼らの秘密のメッセージを取得できるようにする方法です。

MIM attakcsについて私が理解していることから、この図に示すように、MIMは詐欺師として機能します。

以下は私のプロジェクトの詳細です。通信する前にgとpの両方で合意していることは理解していますが、署名を検証するための証明書を持っている場合、どうすればこれを実装できますか？

アリスは⟨signA（NA、Bob）、pkA、certA⟩を準備します。ここで、signAはアリスが使用するデジタル署名アルゴリズム、「Bob」はボブの名前、pkAはXに従ってエンコードされたgxmodpに等しいアリスの公開鍵です。 Diffie-Hellman鍵交換で指定されている固定g、pの場合は509であり、certAは、署名を検証するアリスの公開鍵を含むアリスの証明書です。最後に、NAは8バイトの長さのナンス（ランダムな文字列）です。

ボブはアリスの署名をチェックし、⟨signB{NA、NB、Alice}、pkB、certB⟩で応答します。アリスは、ナンスNAをチェックし、Diffie-Hellman鍵交換に従って、pkA、pkBに基づいてジョイントキーを計算するというメッセージを受け取ります。次に、アリスはメッセージ⟨signA{NA、NB、Bob}、EK（MA）、certA⟩をボブに送信し、Bobrespondswith⟨SignB{NA、NB、Alice}、EK（MB）、certB⟩。

ここで、MAとMBは対応するシークレットメッセージです。

Diffie-Hellman鍵交換中の中間者攻撃のメカニズムについて、私は疑問を持っています。鍵共有通信中に発生する可能性があると聞きました。ただし、CA（認証局）が存在する場合、受信者は送信者の公開鍵を受信したときに送信者を認証できます。したがって、中間者攻撃はどのようにして可能でしょうか？

asp.net でログイン制御の内部を調べようとしています。公開鍵暗号化アルゴリズムを使用して鍵を交換し、それを対称鍵としてさらに通信するために使用しますか。

また、ログイン制御で Diffie Hellman を具体的に使用したい場合のように、暗号化アルゴリズムの選択についても意見がありますか。それは可能ですか、どうすればこれを達成できますか?