問題タブ [diffie-hellman]

DiffieHellmanの実装で問題が発生しています。私はこのコードを使用しています http://www.java2s.com/Tutorial/Java/0490__Security/DiffieHellmanKeyAgreement.htm

実は私が読んでいる一冊の本の例です。しかし、なぜgenerateSecret()ごとに異なるキーを作成するのか理解できませんKeyAgreement。KeyAgreement同じ関数で2回呼び出しても、関数が異なるキーを作成することに気づきました。誰かが提案する何かを持っているなら、私は本当にうれしいです！

御時間ありがとうございます！

MS CNG と別のデバイスの間で ECDH キー交換を実行しようとしています。物事をデバッグするために、CNG で生成されている共有シークレットを確認して、他のデバイスで生成されたシークレットと比較できるようにしたいと考えています。これを行う方法を知っている人はいますか？

Diffie–Hellman は、両側が認証されている場合にのみ安全な鍵交換を提供します。認証のために、サイドは公開/秘密鍵を使用しています。したがって、A 側が B 側の公開鍵を知っている場合、A は単純にその鍵を使用してメッセージ (または新しいセッション鍵) を暗号化できます。なぜわざわざ別の鍵交換アルゴリズムを使用するのですか?

私たちが知っているように、2つの大きな素数に基づくDHアルゴリズムは、素数と素数と呼ばれていました。

DH鍵交換アルゴリズムを実装したアプリを書いています。セキュリティの観点から、素数と基数の保護に注意する必要がありますか？そして、私がそれをしなかった場合、どのような影響がありますか？

DHE_DSS を go の crypto/tls パッケージに実装しようとしています。残念ながら、PreMasterSecret (Z) を同じにすることはできないようです。私の基本的なワークフローは次のとおりです。

サーバーキー交換メッセージを受信

• P、G、Ys を抽出
• 提供されたデジタル署名を使用して検証する

クライアント鍵交換メッセージの準備

• クライアントの Xc を作成する
• Yc を生成 (Yc = G^Xc % P)
• Z の生成 (Z = Ys^Xc % P)
• 次のように梱包して、Yc を返送します。

ただし、これを gnutls-serv でデバッグすると、2 つの PreMasterSecret (Z) が異なります。返された Yc に署名する必要がありますか、それとも別の方法でパックする必要がありますか? RFC 5246には、これを示唆するものは何もありません。

<-- 編集 -->

ここに私の変更のパッチがあります：

https://08766345559465695203.googlegroups.com/attach/48587532c74b4348/crypto.patch?part=4&view=1&vt=ANaJVrHbwydqEZc3zjUWqQ5C8Q5zEkWXZLdL0w6JJG3HYntOlBurUTY7mc9xR9OTfE0bJxs4eeL5a5SGd2jj9eIfXcwJQgLvJchXOgkYKBBynbPfshY8kuQ

SSLSocket (ポート 443) でリッスンする Java ソケット サーバーと、それに接続する iOS アプリケーションがあります。iOS 5.1で実行している場合、サーバーの Java バージョンをJDK 1.5から1.6 (または1.7 )にアップグレードすると、アプリケーションが動作しなくなりました。アプリは、iOS 6 で実行する場合、JDK 5 および 6 に問題なく接続します。

iOS アプリがエラーを報告しています: -9809 = errSSLCrypto。Java 側では、javax.net.ssl.SSLException: Received fatal alert: close_notify.

Java サーバー側では、利用可能なすべての暗号スイートを有効にしました。クライアント側では、いくつかの異なるスイートを有効にするテストを行いましたが、各スイートを個別に有効にするテストはまだ完了していません。今のところ、TLS_DH_anon_WITH_AES_128_CBC_SHA他のもので失敗しましたが、使用すると失敗し、スイートではないと思い始めています。

これがデバッグ出力です。それはずっとServerHelloDone続き、その後すぐに失敗します：

参考までに、これは iOS 6.0 で動作します

DH パラメータを生成するときに Bouncy Castle Provider を使用すると、パフォーマンスに問題が発生します。以下の Bouncy Castle の例が、標準のプロバイダーを使用した場合よりも約 50 倍遅い理由を知っている人はいますか?

Bouncy Castle プロバイダーの使用:

標準プロバイダーの使用:

Diffie-Hellman (DH) は完全転送秘密を提供しますか? それとも一時的な Diffie-Hellman (DHE) のみの機能ですか? Elliptic Curve Ephemeral diffie-Hellman (ECDHE) は DHE より優れていますか?

Diffie-Hellman KeyAgreement アルゴリズムをテストしています。そして、それを使用して秘密鍵を生成します。しかし、 を取得した後SecretKeySpec、それを使用して を初期化するという問題に直面していますCipher。これが私のコードです：

DiffieHellmanモジュール

DHTest

私は初心者プログラマーです。Diffie-Hellman 鍵交換を使用して、クライアントとサーバー間のデータ転送を保護するように依頼されました。この問題についてよく検索しましたが、大きな整数pとg.

問題は、これらの番号を使用して情報の転送を保護する方法がわからないことです。整数ではなく、クライアントとサーバー間の接続を介して「文字列」を転送したいと思います。これらの数値はどのように役立ちますか? 受講中のコースのこのプロジェクトの締め切りが近づいていますが、本当に助けが必要です。