問題タブ [encryption]

SslStream は、暗号タイプ、キーの長さ、ハッシュ アルゴリズムなどをピア SSL スタックとネゴシエートすることになっています。コードで使用すると、ネゴシエーションが常にデフォルトで RC4 と MD5 になることがわかりました。セキュリティを強化するために 3DES または AES を使用したいと考えています。

Web を見回すと、この問題への参照はわずかしかなく、解決策はありません。ある投稿者は、2 つのスタック間の最小公分母が安全であると同時に、高速である/使用する CPU リソースが少ないという追加の利点があるため、これは実際に理にかなっていると主張しています。これは技術的には正しいかもしれませんが、複雑さとコストの間の私の特定のトレードオフは別の場所にあります (私は長いキーで AES を使用することを好みます)。

誰かが助けることができれば、私はそれを感謝します.

openssl ライブラリ (DES 暗号化) を使用して暗号化/復号化を提供するレガシー C++ モジュールがあります。そのコードを Java に変換しようとしていますが、DLL や JNI などに依存したくありません... C++ コードは次のようになります。

Java コードは次のようになります。

したがって、Java で DES 暗号化をかなり簡単に行うことができますが、まったく異なる方法で上記のコードと同じ結果を得るにはどうすればよいでしょうか? 特に気になるのは、C++ バージョンは 2 つのキーを使用するのに対し、Java バージョンは 1 つのキーしか使用しないという事実です。CBC モードでの DES に関する回答は非常に満足のいくものですが、まだ動作させることはできません。元のコードの詳細は次のとおりです。 unsigned char key1[10]= {0}; unsigned char key2[50]= {0};

私が読んだことから、キーは 56 (または 64、私にはわかりません) ビット長である必要がありますが、ここでは 48 バイト長です。

ソフトウェア製品に AES 暗号化を追加したいが、データのサイズが大きくなることが懸念されます。データのサイズが大きくなると推測しているので、それを補うために圧縮アルゴリズムを追加する必要があります。

Java や C# などの一部のプログラミング言語には、標準ライブラリに暗号化パッケージが含まれています。Python や Ruby などの他のものでは、強力な暗号化を行うためにサードパーティ モジュールをダウンロードする必要があります。これは法的な理由によるものだと思います。おそらく、Sun Microsystems には訴えられることを恐れない十分な数の弁護士がいますが、Guido van Rossum はより脆弱だと感じています。

しかし、法律は実際にこれについて何を言っているのでしょうか? この時点で、オープンソースの作成者は、プログラミング言語の標準ライブラリに強力な暗号化を含めた場合、心配することはありますか? もしそうなら、なぜ彼らはしないのですか？そうでない場合、Sun と Microsoft はどうすればそれを回避できますか。

Oracle 9 と JDBC を使用しており、DB に挿入された CLOB を暗号化したいと考えています。理想的には、プレーンテキストを挿入して、ストアド プロシージャで暗号化できるようにしたいと考えています。

プレーンテキストは 4000 文字を超えることはないと予想されますが、暗号化するとテキストが長くなります。現在の暗号化のアプローチでは dbms_obfuscation_toolkit.DESEncrypt() を使用していますが、varchar のみを処理しています。以下は機能しますか？

一時的な clob について混乱しています。閉じる必要がありますか？それとも私は完全に軌道から外れていますか？

編集：難読化の目的は、データへの些細なアクセスを防ぐことです。もう 1 つの目的は、既に varchar 列を難読化しているのと同じ方法で CLOB を難読化することです。オラクルのサンプルコードは、私の特定の問題がある場所である clob を処理しません。varchar (2000 文字未満) の暗号化は簡単です。

パスワードに最小の長さを課すことは（ユーザーを自分自身から救うために）非常に理にかなっていることは理解できますが、私の銀行ではパスワードの長さを6〜8文字にする必要があり、疑問に思い始めました...

• これにより、ブルートフォース攻撃が容易になりませんか？（悪い）
• これは、パスワードが暗号化されずに保存されていることを意味しますか？（悪い）

（うまくいけば）彼らのために働いている優秀なITセキュリティ専門家がいる誰かが最大パスワード長を課している場合、私は同様のことを考える必要がありますか？これの長所/短所は何ですか？

機密データを処理するWCFサービスがあります。そのデータが公開されないようにしたいので、netTCPBindingを検討しています...主に、データが実行されるネットワークを制御でき、パフォーマンスが優先度が高いためです。

暗号化できる領域には、トランスポートレベルとメッセージレベルの2つがあることを認識しています。トランスポートレベルで暗号化するために証明書を使用するつもりです。これは、TLSoverTCPを使用していることを理解しています。

呼び出し元のクライアントも私のものなので、トランスポートレベルを制御します。トランスポート層に変更はないと予想しているので、メッセージレベルの暗号化を気にする必要がありますか？トランスポートを変更する柔軟性が必要でない限り、不要のようです。

POSTリクエストを受け付けるサービスを開発中です。一部のデータは、フォームの非表示フィールドに保存されるためPOST、暗号化する前に暗号化する必要があります。POST

アプリケーションは C# で記述されていますが、サードパーティのクライアントが簡単に統合できるようにしたいと考えています。ほとんどのクライアントは、PHP、Classic ASP、または VB.Net を使用しています。

サードパーティは暗号化のみを行う必要があります。復号化を行います。双方向通信はありません。

暗号化アルゴリズム、パディング モード、およびその他のオプションの最も互換性のある組み合わせは何ですか?

潜在的には約 3 ～ 4 文字しかないが、約 20 文字になる可能性がある文字列を暗号化したいと考えています。情報も解読できるようにしたいので、ハッシュ関数 ( md5、sha1、cryptなど) は適していません。mcrypt拡張機能には、非常に多くの可能性があります。

短い文字列を安全に暗号化するための最良の方法とその理由について、誰か考えがありますか? カジュアルなプログラマーに実用的な暗号化シナリオを紹介する資料へのリンクはありますか?

最近セキュリティ監査を実施したところ、ここにあるシステムのいくつかの弱点が明らかになりました。その結果生じたタスクの 1 つは、パートナー資格情報システムを更新してより安全にする必要があるということです。

「古い」やり方では、(悪い) パスワードを生成し、それを ID とともにパートナーに渡し、パートナーはその ID とそのパスワードの Base 64 でエンコードされたコピーを、すべての XML 要求と共に https 経由で送信していました。 . 次に、それらをデコードして検証します。

これらのパスワードは変更されません (その場合、パートナーはそれらを変更するためにコーディング/構成の変更を行う必要があり、複数の環境で何百ものパートナーとパスワードの有効期限を調整するのは悪夢になるため)、人間がパスワードを入力する必要はありません。または人間が読める形式。私たちのパートナーにとってより良いが比較的単純な実装があれば、私はこれを変更することにオープンです.

基本的には、Java パスワード生成システムをより安全にする必要があることと、それらが安全な方法で送信されるようにすることの 2 つに帰着します。

手巻きのパスワードジェネレーターをいくつか見つけましたが、これを行うための標準的な方法として本当に目立ったものはありませんでした (おそらく正当な理由による)。また、https を介した単純な Base 64 エンコーディングよりも安全な方法で送信することもできます。

パスワードジェネレーターに対して何をしますか? また、現在の送信方法は十分に安全だと思いますか?

編集: XML は SOAP メッセージに含まれており、資格情報は XML 自体ではなくヘッダーにあります。また、パスワードは設定時にパートナーごとに 1 回限りの操作であるため、ジェネレーターの効率についてはあまり心配していません。