事前共有秘密は暗号化に十分ですか？
仮定：
AとBは、最初は同じキーを持つように構成されています。
-キーはペアだけが知っています
-キーを公開する必要はありません
Aには、メッセージ（プレーンテキスト）mを受け取り、それをキーkで変更して、暗号化されたメッセージ（暗号文）cを生成するアルゴリズムaがあります。
Bは同じキーkを持っており、アルゴリズムbがcとkを使ってmを再現できるようにします。
aとbは現在利用可能です。一番好きなアルゴリズムをプラグインします。
次に、AとBは不変に設定されます。
次に、AとBは引き離され、脆弱な媒体を介して通信する必要があります。
AはBにのみメッセージを送信します。
Bは、受信したメッセージをリッスンし、ACKのみを提供します。
Bが悪意のある入力を取得できることは知っていますが、悪意のある入力は復号化されてゴミになりませんか？
キーとアルゴリズムが分離される前に最初に設定された場合、Aをスプーフィングできますか？
キーとアルゴリズムは事前に確立されているので、メディア全体に何も明らかになりませんよね？ AとBが不変である場合、内部的に変更/妥協することはできません。
私が見ることができる唯一の違反は、AまたはBが完全に取得され、キーがアルゴリズムの1つと一緒に取得されたかどうかです。
この方法が脆弱な他の方法はありますか？
ps。この概念は、少なくともある種の追加の機密性を提供するのに十分なアルゴリズムに適用できるように思われたため、特定のアルゴリズムを指定しませんでした。
はい！
サイファーはあらゆる種類の形をとることができます。定義上、必要なのは秘密だけです。
それが十分に安全であるという意味ではありません...
http://www.brighthub.com/computing/enterprise-security/articles/65254.aspx
編集：あなたが実際にそのようなものを本番環境に実装することを提案しているなら、私は他の投稿で熟練したアドバイスを繰り返します。実績のあるアルゴリズムとライブラリを使用します。これは通常、シナリオでは、AがBの公開鍵で暗号化し、BがBの秘密鍵で復号化することを意味します。
また、AまたはBが落ちたら、それは完全な災害だと考えてください。攻撃者は、ネットワーク内の任意のポイントを偽造したり、メッセージを作成したり、ネットワークを通過した、またはこれから通過するメッセージを読み取ることができます。
秘密鍵暗号化は、それを前提としてあなたを保護するのに十分強力です
- 十分に強力なアルゴリズムを使用しています
- キーに十分なビットがあります
- エンドポイントマシンが紛失したり盗まれたりすることはないと確信しています。
- キーを盗む可能性のある不満を持った従業員に対処する必要はありません
- ＃3と＃4に対処するために、セキュリティイベントに応じて、また定期的なスケジュール（キーのサイズに応じた頻度）でプロアクティブにキーをロールして新しいキーを配布する手段があります。
プロトコルには間違いなく問題がありますが、必ずしも質問者の暗号化スキームに問題があるとは限りません。
このプロトコルはリプレイ攻撃を許可します。つまり、エンティティRはAがBに送信するメッセージをキャプチャし、Aがメッセージを送信することを意図していなくても、メッセージの内容を知らなくてもメッセージを再送信できます。次に、それらのメッセージに何が含まれているかになります。たとえば、AとBがコンピュータであり、AがBにメッセージを送信して再起動し、別のエンティティEがそれをキャプチャするとします。これで、メッセージを再生してBの動作を観察するだけで、EはBを希望どおりに動作させるだけでなく、内容を確認できなくてもメッセージの意味を理解できます。
2番目のタイプの攻撃は、別のエンティティMがAを偽装し、大量のメッセージを送信してBを送信し始める可能性があることです。 Bはそれらが信頼できるソースからのものであるかどうかわからないため、Bはそれらのメッセージを復号化しようとし、リソースを消費します。 Mはランダムなデータを作成して送信するだけなので、Mはそれほど多くのリソースを必要としないかもしれませんが、Bはリソースを使い果たし始めます。これはDOS攻撃です。
別の攻撃では、MがAがBに送信するメッセージをキャプチャし、Bに代わってACKで応答します。これは、以前の交換でキャプチャしたものです。 Bは実際のメッセージを取得することはなく、メッセージを取得しなかったことを知りません。メッセージをACKしたのはBではなくEであったことをAは決して知りません。
この方法で構築できる他のより高度な攻撃があります。ここにリストしたものは、通常、安全なプロトコルを設計するときに見られる導入攻撃です。
セキュリティには、暗号化だけでなく、非常に多くのものが付属しています。暗号化は、セキュリティに関する1つの側面を解決しますが、最も重要な側面です。しかし、あなたの場合、安全ではないプロトコルも設計しているので、既存のプロトコルを使用したほうがよいでしょう。
そこで、適切なハンドシェイク、認証（相手が正しいことを確認するため）を実行し、リプレイ攻撃などに対する保護を提供するセキュリティプロトコルが登場します。中間者攻撃は依然として脆弱性である可能性があります（そうでない場合）。つまり、公開鍵インフラストラクチャを信頼します）。ただし、あなたの場合は、AとBが共有シークレットを持っているため、これを解決できます（実際、AとBは誰も信頼していないため、共有シークレットから始めていると思います。他の世界では-通常、秘密を共有する正当な理由です。）
ところで、そのようなセキュリティプロトコルを取得すると、相互に送信する必要のあるすべてのデータが与えられると、セキュリティトークンが作成され、すべての関係者がその中に含まれているもの、エンコード方法などを相互に理解できるようになります。 。（例：ナンス、キー、暗号化されたデータ、デジタル署名など）
本質的に、IMOは、独自のセキュリティプロトコルを作成しようとしています。すでに述べたように、既存のプロトコルから始めたほうがよい場合があります。
あなたはいくつかの大きな誤解を持っているようです。ソルトは暗号化の一部ではなく、ハッシュの一部です。ストリーム暗号で使用されるIVまたは初期化ベクトルと呼ばれる暗号化にも同様の概念があるため、ストリーム暗号の出力を分析するのは困難ですが、メッセージの各ブロックがに依存している場合にのみ利点があります。その出力の前の従属ブロック（つまり、チェーンモードです）。
暗号化の基本的な前提は、メッセージ（プレーンテキスト）が何らかの秘密（キー）を介して、キー（暗号文）なしでは理解しにくい形式に変更されることです。簡単に解読できるシステムから、適切に従えば解読が非常に難しい（または不可能でさえある）システムまで、さまざまなレベルのセキュリティを備えたこのようなシステムが長年にわたって数多く存在しています。
提供される保護の強度は、キーのランダム性と、分析に抵抗するアルゴリズム自体の強度に依存します。これは、実際に理解するのが非常に難しい部分です。