問題タブ [encryption-symmetric]

対称暗号化を使用して、actionscript 3 (クライアント) から python (サーバー) にデータを渡そうとしています。

私が使用しているライブラリは as3crypto と pycrypto です。これらのライブラリを正しく使用しているかどうかはわかりません。

アクションスクリプト 3:

これは、上記の関数の base64 でエンコードされた出力です。

xvVqLzV5TU4=

ここで、pycrypto ライブラリの同じキー、初期化ベクトル、およびアルゴリズムを使用すると、異なる出力が得られます。

パイソン:

I82NQEkSHhE=

両方のライブラリで「testtest」をbase64エンコードして同じ出力を受け取ることができるため、暗号化プロセスに何か問題があると確信しています。

アクションスクリプト 3:

収量...

dGVzdHRlc3Q=

パイソン:

収量

dGVzdHRlc3Q=

誰かがpythonまたはactionscriptのいずれかで同じIVを使用して同じ文字列を暗号化およびbase64エンコードして、実際にどのライブラリが正しい出力を生成しているかを知ることができますか?

私はクライアントサーバーゲームを持っています。クライアントはサーバーに接続し、ゲーム中（約5〜60分）接続を維持します。

新しいクライアントが安全に登録できるようにし、既存のクライアントがログイン資格情報が公開されることを心配せずに認証できるようにしたい。

重要なのは、パフォーマンス上の理由から、ゲームセッションではRC4のような単純で安価な暗号化を使用するのが最善ですが、対称鍵では登録手順を簡単に保護することはできません。

とにかく別のログインサーバーを保持したいので、私の考えは次のようになります。

1. クライアントは、資格情報（または登録情報）を使用してHTTPS要求をログインサーバーに送信します
2. ログインサーバーはユーザー情報を収集し、一時的なRC4セッション暗号化キーを生成します
3. ゲームサーバーとログインサーバー間で共有される秘密対称鍵を使用したユーザー情報+RC4セッション+タイムスタンプ+ダイジェスト（両方のサーバーが時間的に同期されることを信頼できます）。
4. パッケージ化されたデータ+RC4セッション暗号化キー+ゲームサーバーへのIPアドレスは、クライアントへのHTTPS要求への応答として送信されます。
5. クライアントはゲームサーバーへの接続を開き、暗号化されたユーザー情報をペイロードとして含む最初の暗号化されていないhelloメッセージを送信します。
6. ゲームサーバーは、（3）でパッケージ化されたデータを解凍します。これで、ユーザーと、使用することになっているRC4暗号化キーがわかります。
7. タイムスタンプがログイン資格情報の有効期限が切れていることを示している場合、エラーがクライアントに返されます（クライアントは新しい情報を取得します）。復号化されたユーザーデータをダイジェストで検証できない場合は、別のエラーが返されます。
8. すべてが正常にチェックされると、サーバーは暗号化されていないLOGIN_OKを送信し、RC4暗号化通信が開始されます。

考えられるセキュリティ上の懸念：

• ゲームサーバーは、復号化したユーザー情報を100％信頼します。これにより、サーバーが完全に分離されます。これはすばらしいことですが、キーが危険にさらされた場合、ユーザーはユーザー情報を完全に偽造する可能性があります。これらのキーをローテーションすることで、これをいくらか軽減できるため、毎日または毎月新しいキーを使用できます。ゲームサーバーとログインサーバーの両方が、キーを管理する3番目のサーバーからこれを取得できます。次の理由から、やり過ぎかもしれません：a）サーバーにソースコードが公開されている侵入の場合、新しいキーで再起動できますb）十分なキー+暗号化により、ブルートフォース攻撃が困難になります（アルゴリズムに関する提案？）

• RC4は最も安全なアルゴリズムではありませんが、最初の512バイト程度を破棄するようにしており、各キーは限られた時間、たとえば24時間のみ有効です。

• 私が見る限り、中間者の影響を受けにくいようです。SSLはRC4セッションキーを保護します。（5）ゲームサーバーに送信されるRC4セッションキーも暗号化されます。可能なのはDoSであり、ユーザーにキーを再度要求させることです。（2）のデータが期限切れになるまでキャッシュされている場合、これによって新しいパケットが作成されることはありません。

• （3）の暗号化は、キーにランダムビットを追加することで改善できます。これらのランダムビットは暗号化されたパケットと一緒に送信され、（5）でゲームサーバーに提示されます。（6）では、ゲームサーバーはそれらのランダムなビットをキーに追加し、その結果を使用してデータを復号化します。このようにすると、攻撃者はパックされたデータがいつ変更されたかを確認できません。

ここで見落としている脆弱性はありますか？

作成されたペイロードの要約：

• クライアントのログインクレデンシャル（SSLで保護）、ログインサーバーに送信
• ユーザー情報+タイムスタンプ+一時的なゲームサーバーセッションキー+ゲームサーバーと共有される秘密キーを使用してログインサーバーによって暗号化されたダイジェスト。クライアントに渡され、変更せずにゲームサーバーに渡されます。a）クライアントが秘密鍵を知らないb）同じデータの再送信を回避するためのタイムスタンプがあるc）コンテンツが正しく暗号化されていることを確認するためのダイジェスト
• ログインサーバーからクライアントに暗号化されたペイロードとともに送信される一時的なゲームサーバーセッションキー。SSLで保護されています。
• クライアントゲームサーバーのログインパケット。ログインサーバーが受信した暗号化されたパケットで構成されます。

暗号化キーの概要：

• 一時的なゲームサーバーセッションキー：暗号化されたゲームサーバー<->クライアント通信のためにログインサーバーによってランダムに生成されます。ログインサーバーによって生成され、クライアントとゲームサーバーに渡されます。
• 秘密のユーザー情報暗号化キー。ゲームサーバーとログインサーバー間で共有され、クライアントをメッセンジャーとしてゲームサーバーにユーザー情報を渡すために使用されます。クライアントはこのキーを所有していません。

中央サーバーからのコマンドをポーリングする分散アプリケーションがあり、それらのコマンドの内容は、各リモート サイトでアプリケーションと共に展開された公開鍵を使用して、秘密鍵によって「署名」されます。各コマンドは秘密鍵で署名され、その署名はコマンドが実行される前に検証されます。

Java で公開鍵と秘密鍵のペアを生成する方法を次に示します。(私は、1024 よりも多くのことを行う必要があることを認識しています)

新しい要件は、単純な比較的安全なコマンドを送信することに加えて、ソフトウェアにインストーラーをダウンロードして実行し、それ自体を更新するように指示するコマンドを送信することです。これは、正しく行わないと大きな穴が開く可能性があります。「更新インストーラーの実行」コマンドは、通常どおり署名され、ダウンロードして実行される実行可能ファイルの md5 も含まれます。そのため、コマンドの署名は正しく (md5 を含む) 必要があり、ダウンロードしたファイルで計算された md5 は、実行前に正しい必要があります。これは、私が考えることができるほとんどの攻撃ベクトルを処理するはずです. 他に気をつけなければならないことはありますか？

そのため、これらのコマンドが発信されたサーバーで秘密鍵を保護することに注意を向けています。その秘密鍵を入手するとゲームオーバーです。そのキーをディスク上でどのように保護すればよいですか?

私の考えは、パスフレーズを使用した対称暗号化を使用して、その秘密鍵を保護することです。

私の現在の解決策は次のとおりです。

(明確にするために例外を削除しました)

これは基本的にソルトをランダムに生成し、パスフレーズを使用してキーを作成し、結果のソルト、IV、および暗号テキストを復号化の準備が整ったファイルに保存します。

しかし、私はここに何かが欠けていると感じています。有効な説明を取得できるように、キーに何らかのタイプの MAC を含める必要がありますか? たぶん、秘密鍵の前に既知のテキストを 5 バイトまたは 6 バイト置くだけの簡単な方法でしょうか? 現在、パスフレーズが正しくない場合、パディング例外が発生するだけですが、常にそうであるとは限らず、一部のパスフレーズがデコードされてジャンクになる可能性があることを読みました。これを防ぐ必要があると感じています。

私がここで正しい軌道に乗っているかどうかを誰かに知らせて、フィードバックを提供してもらえますか。これを可能な限り安全にすることが重要です..

ユーザーがクライアントのイントラネットアプリでオンラインフォームを作成および管理できるようにするCMSシステムを構築しました。

もちろん、フォームで処理されるデータの一部は暗号化する必要がある場合があります。たとえば、システムを使用して給与の詳細などを処理するフォームを作成する場合などです。AESManagedそのため、アプリケーションデータベースに入る前に、この種のデータを対称的に暗号化するためにクラスを使用しています。

shared secretすべて問題ありませんが、リリース前に、とに関するステアを使用できましたsalt。

私の最初のアイデアは、暗号化されたフィールドを含む（GUIDベースの）IDとフィールドの（再びGUIDshared secretベースの）IDを組み合わせて（動的）を作成することでした。FormQuestion

MySaltは現在同じ方法で生成されますが、Guidの順序が逆になっているだけです。

私はこのようなものに慣れていないので、これが賢明な戦略なのか、それとも他の方法でやるべきなのかわからないのですか？

私はAESでプロジェクトを行っています。誰かが同等の逆暗号で働いたことがありますか？私はその根底にある概念とCでの実装方法を研究しています。

ユーザーとパスワードのペアをクライアントの.NETアプリケーション（Outlookアドイン）に安全に保存する必要があります。

暗号化は可逆的である必要があります。逆アセンブルは簡単に実行できるため、暗号化キーをコードに保存しないようにできれば幸いです。

実際、 EFSのようなAPIにアクセスして、暗号化をWindowsに委任したいと思います。

この問題に関するヒントはありますか？

いくつかのドキュメントをクラウドに保存する必要があり、検索用にドキュメント、ドキュメントメタデータ、単語/フレーズを保存する必要があります。

私の計画では、ドキュメント全体を暗号化するために対称暗号を使用する予定ですが、各単語をハッシュする正しい方法がわかりません。安全なものが欲しいのですが、不必要に各単語の文字数を増やしたくありません。

ドキュメントに対して対称暗号化を行うのに最適な実装はどれですか。また、単語やフレーズを必要以上に大きくすることなくハッシュするための最良の方法は何ですか。

SAML 2.0 で SAML 属性に対して対称暗号化を実行できますか? 非対称にできるようです。長所と短所は何ですか？

暗号化と.NETFrameworkに慣れてきたところです。多くの例を見た後、.NETクラスを使用するときに混乱するパターンが繰り返されているのがわかりますRfc2898DeriveBytes。このクラスを使用して暗号化キーと初期化ベクトルを取得する場合、同じメソッドが使用されているようです。

キーと初期化ベクトルの取得を示すMSDNブログのコードを次に示します。

これは他の場所でも使われているのを見たことがあります。こんな感じだと思っていたのではないでしょうか...

私はここで何かが欠けているに違いありません。キーと初期化ベクトル（IV）が単なる乱数である場合、適切なパスワードとソルトを使用すると、それらはどのように再度取得されますか？

私は、.NET アプリケーションで使用する暗号化/復号化クラスの作成について調査を行ってきました。秘密のパスワードに加えてソルトが必要だということを何度も読みました。今日、単一のパスワードのみを使用する暗号化/復号化方法に出会いました。ソルトを使用していないように見えるため、このコードで使用されている暗号化方法に何か問題がありますか?