問題タブ [diffie-hellman]

ここにMSDN の記事がありますが、あまり進んでいません。

ここでは で失敗しますNTE_BAD_DATA。を使用してMS_DEF_DSS_DH_PROVいます。何を与える？

OK-- Mikeのおかげで、Wincrypt に Diffie-Hellman 鍵ペアを生成させることができました。公開鍵をエクスポートする方法と、相手の公開鍵をインポートする方法を見つけました。ドキュメントによると、相手の公開鍵をインポートすると、共有秘密が計算されます。偉大な。

私は今、その共有された秘密を手に入れる必要がありますが、それは不可能だと思います. アルゴリズム IDを何かに変更するために呼び出さない限り、単純CryptExportKeyにタイプで呼び出してもPLAINTEXTKEYBLOB失敗します。しかし、私は他の何かが欲しいのではなく、共有された秘密が欲しい. ただし、API はこれを思いとどまらせるように設計されているようです。CryptSetKeyParamCALG_AGREEDKEY_ANY

そこに何かアイデアはありますか？ここでの問題は、WiFi Protected Setup の実装の片面しか書いていないことです。したがって、プロトコルは私のために定義されており、相手は私に HCRYPTKEY を与えていません。

IPSecフェーズ1ネゴシエーションを完全に理解する必要があります。今、私はこれを3つのステップに分けます：

1. アルゴリズムの交渉
2. 鍵交換データ
3. 身元

私はWiresharkを使用してプロセスを調査していますが、これまでのところ、最初の部分（Algorithm Negotiations）を完全に理解しています。

私の現在の問題は、2番目の部分である鍵交換データにあります。

使用されているアルゴリズムは、AES-CBC-256ビット、事前共有キー、MD5および1024ビットグループです。

「ISAKMPペイロード」->「KeyExchangeペイロード」->「KeyExchangeData」は私を超えています...それが何であるかわかりません..MD5の事前共有キー？暗号化されていますか？

ここでこの質問をするのは適切ではないかもしれません...とにかく、DHの実装にgmpライブラリを使用しようとしていますが、ここで得た問題は次のとおりです。

一度、出力を観察するためにテストを行っていたとき、素数と秘密鍵の大きな値が選択されましたが:

• p は 10 進数で約 300 桁以上の長さでした
• a、bの長さは約100桁でした

最後に、おそらく10進数で10 ^ 8より小さい、非常に小さい共有秘密鍵を取得しました...

この問題は何度も発生することはなく、実際にはすべての観測中に 1 回だけ発生しました...しかし、これはあまり良くありませんでした。

だから、これを回避できるいくつかの方法があるのだろうか...どうもありがとう

これは、DHキーペアを生成するために使用しているコードです。

（もちろん、必要なtry / catchなしで）。

このようなコードを繰り返し実行し、キーサイズを変更していくつかのテストを実行しました（特に、128から128ステップで1024までランプアップします。1024が望ましいサイズになります。

まず、各サイズの生成を10回実行して、結果の標準偏差を最小限に抑えると、結果の変動が大きくなります。とにかく、キーの作成に必要な時間（1024ビット）は683027msで、これは約に切り上げられます。キーを作成するための11分。

質問は次のとおりです。

1. 他の誰かが同じ結果を得ていますか？
2. より短い時間を達成するために実行されるいくつかの最適化はありますか？
3. 変動の大きいものは何に依存しますか？（つまり、1024ビットキーを生成する場合、18秒から30分かかる場合があります...）

Nexus-One電話でテストが実行されました

「問題」に光を当ててくれてありがとう

よろしく

I am trying to devise a security scheme for encrypting the application level data between a silverlight client, and a php webservice that I created. Since I am dealing with a public website the information I am pulling from the service is public, but the information I'm submitting to the webservice is not public. There is also a back end to the website for administration, so naturally all application data being pushed and pulled from the webservice to the silverlight administration back end must also be encrypted.

Silverlight does not support asymmetric encryption, which would work for the public website. Symmetric encryption would only work on the back end because users do not log in to the public website, so no password based keys could be derived. Still symmetric encryption would be great, but I cannot securely save the private key in the silverlight client. Because it would either have to be hardcoded or read from some kind of config file. None of that is considered secure. So... plan B.

My final alternative would be then to implement the Diffie-Hellman algorithm, which supports symmetric encryption by means of key agreement. However Diffie-Hellman is vulnerable to man-in-the-middle attacks. In other words, there is no guarantee that either side is sure of each others identity, making it possible for communication to be intercepted and altered without the receiving party knowing about it. It is thus recommended to use a private shared key to encrypt the key agreement handshaking, so that the identity of either party is confirmed.

This brings me back to my initial problem that resulted in me needing to use Diffie-Hellman, how can I use a private key in a silverlight client without hardcoding it either in the code or an xml file.

I'm all out of love on this one... is there any answer to this?

EDIT:

Remember that this is about a custom PHP web service that I rolled out on my own.

I found an RSA implementation i can use in Silverlight. It seems pretty safe to use this to encrypt the handshake for the DiffieHellman key agreement between the Silverlight client and PHP web service, and subsequently also use it to encrypt the symmetric key that was agreed upon (which is itself generated from the result of the key exchange by hashing it).

After this I'm pretty much guaranteed that all communication going to the web service has not been intercepted, modified and then retransmitted (MITM). However I believe it is still possible; technically, for an attacker to impersonate the silverlight client and send messages to the webservice (assuming they discover the url).

Security from unauthorized access is provided since the attacker does not know the "secret api" of my custom webservice, hence they are unable to communicate with it.

The only way to break this would be to brute force the webservice with whatever strings an attacker may suspect to be valid to try and get a response from the web service. I don't think you can brute force a variable length string. It sounds impractical.

Does anyone see a problem with this approach?

楕円曲線 diffie hellman の計算は、ここで定義されている標準的なものとは少し違っているように見えますか?

それとも、g、a、p、および b を選択する特定の方法ですか? とにかく、g、a、p、および b はどのように選択されますか?

RSA暗号化Diffie-Hellmanハンドシェイクにより、安全な通信が可能になりますか？SilverlightクライアントからphpWebサービスへの通信を暗号化しています。Silverlightクライアントは、RSA公開鍵暗号化DHパラメーターをWebサービスに送信することにより、鍵共有を開始します。Webサービスのみが秘密鍵を持っているため、MITM攻撃は不可能です。Webサービスはプレーンテキストの回答をクライアントに送り返し、キーが合意されます。次に、このキーを使用して、WebサービスとSilverlightクライアント間の通信をAESで暗号化します。これも、RSA公開キーで暗号化されます。

誰かが欠陥を見ますか？

モバイル/サーバー セキュリティ関連のプロジェクトに取り組んでいます。私は現在、Diffie-Hellman 鍵合意部分の生成に行き詰まっています。サーバー側のプログラムでは正常に動作しますが、モバイル側では動作しません。したがって、Androidとの互換性はないと思います。

次のクラスを使用してパラメーターを取得しました。3 つの値のカンマ区切りの文字列を返します。最初の数値は素数 P です。2 番目の数値は基底生成元 G です。3 番目の数値は乱数指数 L のビット サイズです。

私の質問は、コードに問題があるか、それとも Android 用に圧縮できないのでしょうか?どのような変更を行う必要がありますか?
あなたの提案とガイダンスは私にとって非常に役立ちます。よろしくお願いします。

よろしく、
セビー