16バイトのデータをAESで単一ブロックとして暗号化することはどの程度安全ですか？ salt/IVなし、操作モードなし、暗号化された16バイトのブロックが何百万もあります。私は暗号については十分に分かっていないが、これは私には匂いがする。AESによる暗号化なしの16バイト暗号化
編集：メッセージを暗号化することではなく、プレーンテキストの長さが16バイトになるデータベーステーブルの列について少し詳しく説明します。データは完全にランダムではなく（最初の8バイトは頻繁に同じになります）、成功した復号化を識別するチェックサムがあります。
私はこの来週に提案している人たちとミーティングに出席し、問題があれば、デザインが安全でないことを示す参考資料へのいくつかの指摘を高く評価するでしょう。私はシステムに完全には慣れていませんが、これでは大回りの再設計が必要になる可能性があるので、多くの抵抗になる可能性が高いと思います。関係する人々（および権力）の大半は、動機が働くシステムを得ることであるビジネス側にあります。
ECBは一般的な用途では安全ではありません。指定されたプレーンテキストは常に同じ暗号テキストに暗号化されるため、パターンを公開することができます。しかし、それが安全である特別なケースがあり、このアプリケーションがその1つである可能性があります。
引用符適用された暗号化、第2版pg。 190は、ブロック暗号のためのECBモードに関して：
プラス側では、同じキーを持つ複数のメッセージ を暗号化するには、セキュリティ リスクがありません。実際、各 ブロックは、同じキーで暗号化された別のメッセージ として見ることができます。
後（P 208）に、シュナイアー氏は述べています：
シンプルさとスピードがあなたのメイン 懸念されている場合は、ECBは、ブロック暗号を使用する最も簡単かつ 最速モードです。それも が最も弱いです。 がリプレイ攻撃に対して脆弱であることに加えて、ECBモードの アルゴリズムは、暗号解読に最も簡単な です。メッセージの暗号化にはECB をおすすめしません。
などのランダムなデータを暗号化する場合は、ECBを使用するのが適切なモードです。 データが短くランダムであるため、 このアプリケーションでは、ECBの問題 の欠点はありません。
共通の接頭辞と小文字は、共通の暗号テキストを生成しません。これは、全体の平文ブロックが複製されている場合にのみ発生します。あなたが説明したことから、あなたのアプリケーションは、ECB —に適しているかもしれません。特に、それぞれのプレーンテキストの値が一意であるならば。
初期化ベクトルまたはIVとも呼ばれる塩なしでは、暗号テキストのセキュリティそして私は、キーも同様に）大幅に削減されると信じています。潜在的な攻撃者は、暗号化されたテキストでパターンを繰り返すことをはるかに簡単に行うことができます。 IIRCこれはMS Officeの暗号化方式をアップグレードするときにMicrosoftが行ったのと同じ基本的な誤りでした。
これは繰り返しパターンがあることを前提としています。 –
暗号化用語では、攻撃者が特定のアルゴリズムとIVを知っている場合のみ、これは安全ではありません。
特定の前提があります。復号化が完了すると、復号化の試行が成功したことを知るためにデータがどのように見えるか攻撃者は知っていますか？例えばMD5、CRC、または復号化の試行が成功したことを確認できる何らかの形式のチェックサムがありますか？その場合は、攻撃者に試行を検証する方法を与えます。
しかし、ハッキングの点では、128ビット暗号のキーの組み合わせは2^128ですが、テラバイトのデータで同じキーを使用するのと同じように安全です。 16バイトのデータは1ブロックだけなので、CBC（Cipher-Block-Chaining）は適用されないため、操作モードは関係ありません。
しかし、塩IVが適用され、その値は鍵自体と同じように秘密でなければなりません。レインボーテーブルは、塩を使用しない暗号に対するブルートフォース攻撃を加速するために使用できます。これはあなたの弱いリンクです。
暗号化では、攻撃者はアルゴリズムとIVを知っていると仮定します。 –
あなたは彼が鍵を知っているとも仮定していますか？どのように復号化されたデータを検証するのですか？あなたはリスクを測ることができますが、特定のことは秘密にする必要があります。私は、あなたの企業がソーシャルエンジニアリングから安全だと仮定していると思います。 – spoulson
@spoulson：攻撃者は、データそのもの（ポイント）とそれを暗号化するために使用される鍵を除いて絶対にすべてを知っていると仮定します。秘密にすることに他の何かを依存させることは、真のセキュリティを提供しない難読化です。 –
AESは暗号文のみの攻撃に対してかなり強力です。しかし、同じキーで多くのプレーンテキストを暗号化すると、既知のプレーンテキスト攻撃と選択されたプレーンテキスト攻撃に対してシステムが脆弱になります。
言われていることは、暗号化キーがランダムで、プレーンテキストが一見無作為である場合、あなたはまだ安全かもしれないと言われています。しかし、私は間違いなく別のキーを使用することを検討します。
一方、プレーンテキストがお互いに関連しているか、一見ランダムではない場合、ECBはまったく安全ではありません。
私は、ショートメッセージのAESの弱点を認識していません。アルゴリズムは十分に満足しているはずです。あなたがしたいですかあなたの会議に取るように
：
1）脅威モデル（何を、いつ、どのような彼らが去る時に起こるを参照するか、「悪い男になるかもしれ方）
2）。
これで、本当にAESを暗号化する必要があるかどうかを判断できるはずです。暗号化は、AESを使用している別の場所で暗号化することができれば、列の値を実際に保護します最後に、「鍵はデータよりも本当に安全ですか？」という質問をします。鍵がtと同じ大きさだったこのようなスキームを見ました彼はデータ（ここではサイズ=「ちょっと小さい」）で、保護していたデータと同様にアクセス可能でした。はい、それはあなたが何をしたのかを攻撃者が把握している間にあなたに数時間を買うでしょうが、それはあなたに強固なセキュリティの方法をあまり与えません。
あなたが助けてくれることを望む希望。あなたの特定のポジションを知らずに、答えを調整するのは難しいです。 :)
正確にどのような種類のデータを暗号化していますか？それが擬似ランダムであれば、あなたは大丈夫でしょう...ブロック間にパターンの類似点がある場合、私の人々が指摘したように、それは悪い考えです。 –