5

暗号化についてはまったくわかりません。しかし、私はそれが必要です。どのように？

非同期メッセージを介してネットワーク上で相互に通信するノードのシステムがあるとします。ノードは、他のノードに関するセッション情報を維持しません (これは設計上の制限です)。

送信されたメッセージを自分のノードだけが読めるようにしたいとします。暗号化はそれに対する解決策だと思います。

ノードはセッションを維持しておらず、通信はステートレスでコネクションレスな方法で機能する必要があるため、非対称暗号化は除外されていると推測しています。

だからここに私がやりたいことがあります：

  • メッセージは UDP データグラムとして送信されます
  • 各メッセージには、メッセージを区別するためのタイムスタンプが含まれています (カウンター リプレイ攻撃)
  • 各メッセージは共有秘密対称鍵で暗号化され、ネットワーク経由で送信されます
  • もう一方の端は、共有秘密対称鍵で復号化できます

単一のノードを侵害することで、明らかにキーが侵害される可能性があります。同時に、このシナリオでは、侵害された 1 つのノードへのアクセスによってすべての興味深い情報が明らかになるため、鍵は最も弱いリンクではありません。

この暗号化にはどの暗号を使用すればよいですか? 鍵の長さは？

ezPyCryptoでサポートされているものを使用したいと思います。

ほとんどの人が指摘しているように、私は AES を使用します。どのモードを使用すればよいですか?

私はezPyCryptoでそれを行う方法を理解できませんでした.PyCryptoはモデレータスワップでハングしているようで、Googleのkeyczarはこれを設定する方法を説明していません.不安をもたらすこと。したがって、ベアボーンの方がよいでしょう。この男は Python で AES 用の優れたモジュールを持っていると主張していますが、これが彼の最初の Python プロジェクトであるとも主張しています。

編集: python 実装の検索を別の質問に移動して、クロバーを停止しました...

4

7 に答える 7

8

暗号化についてはまったくわかりません。しかし、私はそれが必要です。どのように？

危険！暗号化についてよく知らない場合は、自分で実装しようとしないでください。暗号化を正しく理解するのは困難です。暗号化システムのセキュリティを破る方法は、実際にキーをクラックする以外にも非常に多くあります (これは通常、非常に困難です)。

注意深いキー管理や暗号化システムの機微に関するその他の理解なしに、ストリーミング データに暗号を平手打ちしただけでは、あらゆる種類の脆弱性にさらされる可能性があります。たとえば、説明したスキームは、ノード間のキー配布に関する特定の計画がなければ、中間者攻撃に対して脆弱であり、配布方法によっては、選択された平文および/または既知の平文攻撃に対して脆弱になる可能性がありますシステムは外界と通信し、暗号と動作モードを正確に選択します。

そのため...安全に使用する前に、一般的な暗号を読む必要があります。

于 2008-10-07T15:24:37.257 に答える
7

最初に考えるべきは、チャネル セキュリティ (SSL/TLS または IPSec のいずれか) です。
確かに、これらの両方に一定のセットアップ オーバーヘッドがあり、特に PKI などに関しては、SSL/TLS よりも IPSec の方が多くなります。プロトコルに応じて、強力な暗号スイートを使用していることを確認してください。

SSL/TLS も IPSec もシナリオ/環境に適合しない場合、次の選択肢はAES (別名 Rijndael) です。
必要に応じて、少なくとも 256 ビット長のキーを使用してください。
キーは、暗号的に安全な乱数ジェネレーター (単純な rnd() 呼び出しではない) によってランダムに生成する必要があります。
暗号モードをCBCに設定します。
PKCS7 パディングを使用します。
一意の暗号ランダム初期化ベクトル (IV) を生成します。鍵を適切に保護および管理することを忘れないでください。定期的な鍵のローテーションを検討してください。

データによっては、キー付きハッシュを実装してメッセージの整合性を確保することもできます。ハッシュにはSHA-256を使用します。

まれにストリーム暗号を使用したい場合もありますが、通常はより複雑になるため、最初は使用しないことをお勧めします。

さて、私は ezpycrypto (または実際には python 全般) に慣れていないため、これがすべてサポートされているとは言えません。しかし、ここにあるものはすべて非常に標準的で推奨されるベスト プラクティスです。あなたの暗号化ライブラリがサポートしていない場合は、サポートしているものを見つけることをお勧めします ;-)。

于 2008-10-05T18:52:23.160 に答える
4

対称暗号の使用を想定すると、他の方法を選択する正当な理由がない限り、AES をデフォルトの選択にする必要があります。

AES を選択するための長い複雑な競争があり、勝者は慎重に選ばれました。暗号の神である Bruce Schneier でさえ、AES の勝者は彼がコンテストに提出したアルゴリズム (TwoFish) よりも優れた選択であると述べています。

于 2008-10-05T18:46:12.920 に答える
3

通常は AES 256 が推奨されますが、場所 (または顧客の場所) によっては法的な制約があり、より弱いものを使用せざるを得ない場合があります。

また、通信ごとにランダムな IV を使用し、それをメッセージと一緒に渡す必要があることに注意してください (これにより、タイムスタンプの必要性も節約されます)。

可能であれば、アルゴリズムに依存しないようにし、メッセージとともにアルゴリズムを渡します。次に、ノードはヘッダーを見て、復号化に使用するアルゴリズムを決定します。こうすることで、特定の展開で必要になったときにアルゴリズムを簡単に切り替えることができます。

于 2008-10-05T18:39:01.547 に答える
1

私はおそらくAESに行きます。

于 2008-10-05T18:26:22.680 に答える
1

非対称暗号化は、このシナリオでも機能します。各ノードに公開鍵を発行させるだけです。そのノードと通信したいノードは、そのノードの公開鍵でメッセージを暗号化するだけで済みます。非対称鍵を使用する利点の 1 つは、鍵の変更と配布が容易になることです。公開鍵は公然と配布できるため、各ノードは公開鍵と秘密鍵のペアを更新して再公開するだけで済みます。ネットワーク全体 (または各ノード ペア) が新しい対称キーに同意するためのプロトコルは必要ありません。

于 2008-10-05T18:42:31.040 に答える
1

安全に通信する必要があるノード間に VPN を作成してみませんか?

そうすれば、わざわざ独自のセキュリティ ソリューションをコーディングする必要がなくなり、静的な共有キーに制限されることもありません (これにより、侵害された場合に、キャプチャされたすべてのトラフィックを事後に復号化できます)。

于 2008-10-05T18:49:11.463 に答える