web-dev-qa-db-ja.com

AES暗号化されたデータセット全体が「クラック」されるために存在している必要がありますか？

クレジットカードにAES 256アルゴリズムを実装していますが、データセットを分割して2つの場所に保持すると、暗号化されたデータセットを強化または脆弱化するのではないかと考えています。 AESアルゴリズムを十分に理解していないため、「クラックのためにすべてのビットが存在する必要があるか」、または暗号化されたデータのサブセットによってクラックが実際に容易になるかどうかを確認できません。

ここにシナリオがあります：

暗号化するテキスト：4798531212123535

アルゴリズム：AES256

Key：b0882e32f1194793800f4f0b43ddec6b273d31aafc474c4c8a3d5ae35b3e104b

暗号化されたデータ：GoCN4o35w4vzU4hQp47CLUgsTgaxRvvT7qdTVh5Hl + I =

Q1：データセットを2つの部分に分割し、それらを国の2つの部分にある2つのリポジトリに保存する場合...危険にさらされましたが、分割してセキュリティを弱めましたか？

Q2：次の質問は次のとおりです。部分的なデータセットとキーが侵害された場合、キーを使用してデータセットの一部を復号化できますか、または勝つためにはデータセット全体が存在している必要がありますか？

パート1：GoCN4o35w4vzU4hQp47CLUgs

パート2：TgaxRvvT7qdTVh5Hl + I =

------------明確にするために追加--------------

パート1とキーが侵害された場合、復号化の結果、何か価値のあるものになるでしょうか？結果は正しい文字シーケンスになりますか？

妥協した値：

パート1：GoCN4o35w4vzU4hQp47CLUgs

Key：b0882e32f1194793800f4f0b43ddec6b273d31aafc474c4c8a3d5ae35b3e104b

復号化された値は次のようになります：47985312（これは元のシーケンスです）

encryptioncryptographyaes
8
troy r

あなたはそれを誤解している。分割などではありません。 思考では、 AES暗号化は、適切に行われていれば「クラック」されません。 AESはシステムで最も堅牢な要素です。これはあなたが心配すべき最後の部分です。

AES暗号化が提供するのは非常に特定の機能です：特定のキーKを使用して、データ（「プレーンテキスト」）を次のようなものに変換します読めない（「暗号文」）except知っている人には[〜＃〜] k [〜＃〜] 、知っているので[〜＃〜] k [〜＃〜]変換を逆にすることができます。 [〜＃〜] k [〜＃〜]が攻撃者に知られていない限り、暗号化されたデータは安全です。 [〜＃〜] k [〜＃〜]が攻撃者に知られている場合、攻撃者は勝利しており、分割、スワッピング、または大霊の栄光を唱えながら火の周りで踊ることはあなたを救います。

AESは128、192、または256ビットのキーを使用します。非常に多くのキーが存在する可能性があるため、攻撃者が純粋な運でキーを危険にさらす可能性はごくわずかです。 128ビットのキーで十分です。より大きなキーは、セキュリティを向上させるためではなく、仲間の開発者の間でアルファ男性のステータスを主張するためのものです。

たとえば、上司が「セキュリティが発生している」という印象を得て、たるみがなくならないように、複雑なデータシャッフルの儀式に本当に取り組む必要がある場合は、適切に行うこともできます。分割しないでください。代わりに、一連のバイト[〜＃〜] c [〜＃〜]（暗号化された文字列）を指定すると、ランダムなバイトのシーケンス[〜＃〜] d [〜＃〜]同じ長さ;次に、「分割」[〜＃〜] c [〜＃〜]を2つの共有に分割します[〜＃〜] c [〜＃〜]1=[〜＃〜] c [〜＃〜]XOR[〜＃〜] d [〜＃〜 ]、および[〜＃〜] c [〜＃〜]2=[〜＃〜] d [〜＃〜]。共有を組み立てるには、XORそれらを一緒に：たまたま[〜＃〜] c [〜＃〜]1XOR[〜＃〜] c [〜＃〜]2=[〜＃〜] c [〜＃〜]。この種の分割は明らかに安全です（学習する攻撃者[〜＃〜] c [〜＃〜]1 または[〜＃〜] c [〜＃〜]2両方ではなく、正確にnothingを 情報理論 の意味で学習します。これは、暗号ができるのとほぼ同じです取得する）。もちろん、あなたが物事を台無しにしないことを条件とします（強いランダム[〜＃〜] d [〜＃〜]を生成しなければなりません）、そして文字列を「分割」するたびに新しい文字列を生成します）。

29
Tom Leek

データを分割することではなく、AESキーの安全な保管について心配する必要があります。キーが危険にさらされている場合、 Kerckhoffsの原則 であるため、データを使用して行った操作と実際には何の違いもありません。

追加のための編集：特に、AESキーは、暗号化されたデータを保持する同じデータベースに格納しないでください。データベースの侵害により、キーとデータの両方が生成されるためです。 SQLインジェクションによるリモートデータベースの侵害例は、OS全体が侵害されていない場合でも可能です。鍵を別の場所に保管することは、多層防御の一部です。理想的には、ハードウェアセキュリティモジュール（HSM）を使用して格納されますが、プログラムにコンパイルされるか、ファイルシステム内のファイルとしても、データベース内のストレージよりはるかに優れています。

4
Bob Brown

この問題へのアプローチを再考することをお勧めします。データはどこに保存していますか？それがデータベース内にある場合、ほとんどのデータベースには、保管されているデータをかなり安全に暗号化する機能があります。データは安全でないチャネル上を移動する必要がありますか？ HTTPSまたはセキュアFTPを調べます。どうしても必要な場合を除いて、暗号をいじらないでください。間違えるのは非常に簡単です。

1
Anthony