問題タブ [diffie-hellman]

以下のスニペットでは、最初の「for」ループから始めて、何が起こっているのか、そしてその理由を説明してください。2番目のループで0が追加されるのはなぜですか、1が追加されるのはなぜですか。bigiの下の「if」ステートメントで何が起こっているのか。最後に、modPowメソッドについて説明します。有意義なご返信をよろしくお願いいたします。

C# でプリミティブな SSH クライアントを作成することに着手しました。プリミティブ ssh 接続 (低レベル)などの投稿で私のことを覚えているかもしれません。

とにかく、DH 鍵交換を開始するまでは順調です。(openssh クライアントから openssh サーバーへの) ssh 接続を確立するときのトラフィックと、クライアントが同じ openssh サーバーに接続するときのトラフィックを比較しました。

OpenSSH クライアント -> OpenSSH サーバー (サーバーは S、クライアントは C): S: SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2\r (挨拶) C: SSH-2.0-OpenSSH_5.2\r (自己紹介) C : Key Exchange Init (0x14 = 20) S: Key Exchange Init C: Diffie-Hellman GEX Request (0x22 = 34) (DH GEX 最小、ビット数、最大) S: Diffie-Hellman Key Exchange Reply (P、 G など) C: Diffie-Hellman GEX Init S: Diffie-Hellman GEX Reply

私のクライアント -> OpenSSH サーバー: S: SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2\r (挨拶) C: SSH-2.0-Some_Name\r (自己紹介) C: Key Exchange Init (0x14 = 20) S: Key Exchange Init C: Diffie-Hellman GEX リクエスト (0x22 = 34) (DH GEX 最小、ビット数、最大)

そして、応答としての偽の TCP パケット (おそらく、サーバー接続は GEX 要求の後/発生時に終了しました。

私はまだ AES128 を使用していません (これが選択された暗号化だと思いますが、これを確認する方法がわかりません...)。などの値を使用して DH 計算を行います。

RFC 4419 ページ 3 http://www.ietf.org/rfc/rfc4419.txt SSH_MSG_KEY_DH_GEX_REQUEST を送信しましたが、サーバーは SSH_MSG_KEX_DH_GEX_GROUP に応答しません。

ここで私が理解していないことについて、誰かが私に少しアドバイスをくれますか? サーバーは私の GEX リクエストを理解していませんか (暗号化を期待しているためか?)?

どんな助けでも大歓迎です、ありがとう:)

Diffie-Hellman 暗号化アルゴリズムを使用する必要があるサードパーティと統合しています。CF ドキュメントは、これがサポートされているアルゴリズムであることを示しています。

「Diffie-Helman」または「DH」のいずれかで呼び出そうとするとEncrypt()、「選択したセキュリティ プロバイダでは、Diffie-Hellman アルゴリズムがサポートされていません」というエラー メッセージが表示されます。

DH を含む別のセキュリティ プロバイダを使用するように CF を構成することは可能ですか? または、これを実現するために Java オブジェクトを直接使用することは可能ですか?

私は、大学のクラスの1つのプロジェクトのために、ルビーでdiffie-hellman鍵交換の実装を書いています。少なくとも500ビット長の大きな（安全な）素数を生成する必要があります。何か案は？OpenSSLライブラリを使用する必要がありますか？もしそうなら、どの機能をお勧めしますか？

私は、 RFC 3526のいくつかの大きなグループを使用して、JavaでDiffie-Hellman鍵交換を実装しました。私の出力はかなり大きなバイト配列です。出力の最初の448ビット（56バイト）をblowfishキーに使用しても安全ですか？バイトを何らかの方法で変換する必要がありますか、それともキーに特定のバイトを選択する必要がありますか？

apache ofbiz ValueLinkApi Class - srcの修正版を使用して、ValueLink 加盟店の作業キーを生成しようとしています。

ofbiz フレームワークのコンテキスト外から実行できるスタンドアロン クラスにする程度にのみ変更しました。

プログラムはエラーなしで実行されますが、キーが API によって受け入れられません。

これを実装したことがありますか？このライブラリを使用しましたか、それとも openSSL のようなものを使用しましたか? このライブラリを使用した場合、まったく変更する必要はありませんでしたか?

ここに私のバージョンがあります:

SSHの仕組みについてもっと理解しようとしています。Wireshark を使用して、マシン間を移動するパケットを取得しています (両端で OpenSSH が実行されています)。Diffie-Hellman Group Exchange Reply パケットでスタックしています。暗号化アルゴリズム名の直後に、RFC 4419 で説明されていない、または記述されていない長さ (4 バイト) と値 (1 バイト) があるようです。RFC によると、このパケットで送信されるデータの最初のチャンクはサーバーの公開鍵と証明書になるとのことですが、このデータを試してデコードするための証明書形式を探す場所がわかりません。

これは、サーバーから受信したパケットです (TCP、IP、およびイーサネットのパケット情報は含まれていません)。読みやすいように広げました。また、私が理解している値とフィールドの目的も示しました。「ホスト キー」、「f」、および「ハッシュ署名」は、RFC 4419 によってこれらの位置にあることが示されています。「->」でマークされた行には、私を混乱させるデータがあります。値 0x23 (35) が関連するものは何も見えません。

RFC 4250-4254 および 4419 を読み、このコード 0x23 の手がかりを見つけようとしましたが、これまでのところ成功していません。RFC で説明を見逃している可能性は十分にあるので、その場合は遠慮なく指摘してください。ヒントや説明は役に立ちます。

ありがとうございました

PKCS #3 で定義されている新しい DH パラメータを生成したい:

バウンシーキャッスルを使用。私の現在のコード

正常に動作しますが、ライブラリを変更する以外に自分でベースを設定する方法がわかりません。私が見逃している回避策はありますか？

前もって感謝します。

AndroidでAESを使用して文字列を暗号化しようとしています。対称鍵は、Diffie-Hellmanアルゴリズムを使用して事前に決定されており、問題ないようです（鍵の長さは128ビットです。以下を参照してください）。
それにもかかわらず、私は InvalidKeyException: "Key length not 128/192/256 bits.「

コード：

上記のコードは、次の出力につながります。

その後、取得InvalidKeyException: Key length not 128/192/256 bits.しますが、ご覧のとおり、SecretKeyの長さは128ビットです。

何か案は？

編集

私はまだこれについてのアドバイスを望んでいます、私は自分の意図を明確にしようとしました...

モバイル通信フレームワークでデバイスのペアリングに出会ったとき、このトピックに関する多くの論文を研究し、ここで以前の質問からいくつかの情報を得ました. しかし、私はプロトコルソリューションを実装する準備ができていなかったので、派生物を発明しました.私は暗号オタクではないので、最終的なソリューションのセキュリティ警告については確信が持てません:

主な質問は

• コミット機能はSHA256で十分？
• コミット文字列に認証情報として共有シークレットを追加することは安全ですか?
• 1024 ビット グループ DH の全体的なセキュリティとは
• MITM 攻撃が成功する可能性は最大でも 2^-24 ビットであると想定しています (24 ビット チャレンジのため)。これはもっともらしいですか？
• 最も有望な攻撃は何ですか (私の麻痺した冷たい手からデバイスを引き裂く以外に)

これはアルゴリズムのスケッチです

• 初めてのペアリングでは、「ピア ツー ピア ワイヤレス ネットワークにおける鍵合意」(DH-SC) で提案されているソリューションが実装されます。私はそれを、以下から派生したコミットメントに基づいています。
  • 通信エンティティ/ロールの修正「UUID」 (128 ビット、プロトコル開始時、コミット前に送信)
  • 公開 DH キー (1024 ビットの Oakley グループに基づく 192 ビットの秘密キー)
  • 24 ビットのランダム チャレンジ
• コミットは SHA256 を使用して計算されます
  • c = sha256( UUID || DHパブ || チャル)
• 両当事者はこのコミットメントを交換し、上記の値のプレーンなコンテンツを開いて転送します。

• 手動認証用に 24 ビットのランダムがユーザーに表示されます。

• DH セッション キー (128 バイト、上記を参照) が計算されます

• ユーザーが永続的なペアリングを選択すると、セッション キーはリモート UUID と共に共有シークレットとして保存されます。

• 次にデバイスが接続すると、ランダム チャレンジの前に以前の DH セッション キーを追加でハッシュすることによってコミットが計算されます。開いたときに転送されないことを確認してください。

  • c = sha256(UUID || DH pub || DH sess || Chall)

• これで、ユーザーは、ローカル パーティが自分自身の保存済みの以前の DH セッション キーを使用して同じコミットメントを取得できる場合、認証に煩わされることはありません。接続が成功すると、新しい DH セッション キーが新しい共有シークレットになります。

これは私がこれまでに見つけたプロトコル (およびそのようなセキュリティ証明) に正確には適合しないため、ここで暗号化を有効にした人から意見を得ることに非常に興味があります. ところで。「EKE」プロトコルについて読みましたが、追加のセキュリティ レベルがどのようなものかわかりません。