問題タブ [encryption-symmetric]

私たちはプロジェクトでいくつかの厳しいセキュリティ要件を実行することを目指しており、パフォーマンスの高い多くの暗号化を実行する必要があります。

PKIは対称暗号化よりもはるかに低速で複雑であることは知っていると思いますが、自分の気持ちを裏付ける数字が見つかりません。

私は暗号化アルゴリズムを調査しています-誰かがRijndaelとAESの違いの簡単な概要を教えてもらえますか？

デスクトップ アプリケーションとモバイル デバイスの間で小さなバイナリ メッセージ (長さ 1 または 2 KB) を転送するタスクがあります。メッセージは非対称に暗号化する必要があります (RSA など)。私が学んだことから、この種のタスクにはハイブリッド暗号システムを使用する必要があります。

1. ランダムな対称鍵を生成
2. プレーンテキストを対称鍵で暗号化 (たとえば AES を使用)
3. 対称鍵を公開鍵で暗号化する
4. 暗号文と暗号化された対称鍵を送信する

暗号文と暗号化された対称鍵を格納するための独自の形式を発明したくありません。そこで、CMS 標準 (暗号化メッセージ構文) に出くわしました。一見すると、私が必要としているものとまったく同じように見えます。標準を正しく理解していれば、暗号文と暗号化された対称鍵、および使用されているアルゴリズムに関する情報が埋め込まれています。

概説されたタスクに CMS 標準を使用する必要があるかどうか、誰にも言えませんか? OpenSSL の CMS サポートは私のニーズに十分ですか?

乾杯、クリスチャン

Triple-DES（> 128ビット）とプレーンDES（64ビット）を混同しているようです。Java 1.5を使用して、トリプルDES（またはDESede）でDerbyデータベースを暗号化しようとしています。

JDK 1.5の問題に関するこのディスカッションフォーラムのメッセージを偶然見つけたので、それが実際にDESedeを使用していて、プレーンなDESを使用していないことを確認しました。トリプルDES（168ビット）URLでデータベースを作成したとき

私はまだそれを開いて、（プレーンな）DES（64ビット）URLでアクセスすることができました

これは私が期待する動作ではありません!!! 間違った暗号化アルゴリズムで開くことができないはずです。正しい（> 128ビット）アルゴリズムで実際に暗号化されていることを確認するにはどうすればよいですか？

Derbyは、JCECipherProvider.javaに記載されているJava1.5に適切な関数を使用しているようです。コードを読んだところ、DerbyはトリプルDESをプレーンDESとは異なり処理していないことがわかりました...強力な暗号化を使用していると本当に信頼できますか？

Alice と Bob の 2 つのクライアントは、サーバーを使用してログインし、サーバーを介してメッセージを交換します。ログイン時に、両方とも公開鍵を送信してサーバーに保存します。Alice が Bob と話したいときは、Bob の公開鍵で対称鍵を暗号化し、それをサーバー経由で Bob に送信します。

サーバーが独自の公開鍵ペアを作成せず、ボブの公開鍵の代わりにアリスに送信しないようにするにはどうすればよいですか。このようにして、サーバーは最初に Alice が送信したものを復号化し、Bob の実際の公開鍵を使用して再度暗号化します。

ありがとう

C#キーで文字列を暗号化するために、次のコードを書きました。

問題は、暗号化されたテキストを次のコードで復号化しようとすると、常にエラーが発生することです。

手がかりはありますか？

そのため、DPAPI を使用して対称キーを保存しようとしています。すべてはうまくいっていますが、エントロピーをどうするのでしょうか? この回答済みの質問は、実際には十分な洞察を提供していません。滑りやすい坂道のように思えます - マシン ストアを使用してエントロピーを保存することもできますが、誰かがそれを行うのを妨げるものは何ですか? 注: ユーザー スコープを使用して現在のキーを保存しています。

だから私の質問は - DPAPI を使用してエントロピーを格納する最良の方法は何ですか?

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?

Microsoft CryptoAPI のテスト アプリケーションを作成しています。2 番目のパーティの公開鍵を使用して一方のパーティの秘密鍵をエクスポートし、その秘密鍵を 2 番目のパーティの秘密鍵としてインポートします (これにより、通信用の共有秘密鍵が設定されます)。これが私のコードです：

そして、これはエラーを与えます:

公開鍵ペアは、次の呼び出しによって、encryptT と decryptT (送信者、受信者) の両方に対して生成されます。

エラーの原因は何ですか？

ありがとう、