どちらがより効果的で「安全」なのか：圧縮+暗号化、または暗号化のみ？
これは、IRC freenodeについての議論で出てきました。そして今、私は興味があります。
誰かが暗号化のみ、または圧縮+暗号化（gpg/pgpが主要な暗号化システムである）がファイルのより良い「セキュリティ」を提供するかどうかを判断したいという考えです。
私は暗号化や暗号化のセキュリティの専門家ではないので、どちらのオプションをもう一方よりもバックアップする必要があるかどうか疑問に思っています。
（本当に「安全」なものは何もないので、ここでは単一引用符を使用しています）
関係する要素がいくつかあります。 1つ目は、暗号化によってパターンが非表示になることです。同じコンテンツが数回繰り返されているファイルがある場合、暗号化によってこの事実が非表示になります。弱い暗号化スキームを使用していて、平文のパターンに関する情報が暗号文に漏洩する場合、圧縮により、漏洩する情報の量を減らすことができます。少なくとも、それは古典理論です。今日使用するのに十分な暗号化スキームは、iselfでパターンをすべて処理する必要がありますが、圧縮または非圧縮（関連するヒント：ECBモードを直接使用しないでください）。したがって、暗号化前の圧縮に関する従来の議論は、もはや関連性がありません（そして、暗号化後の圧縮は、ほとんどすべての場合に無意味です）。
もう1つの「古典的な」議論は、暗号を解読する可能性は、操作する必要のある暗号文の量とともに増加するということです。したがって、送信前にメッセージを圧縮すると、攻撃者が操作する素材が少なくなります。繰り返しになりますが、現代の概念で安全な暗号については、これについて心配する必要はありません。アルゴリズムとキーサイズを時々更新し、最新の推奨事項に従って、キーをローテーションするなどして更新する必要があります。ただし、これに対する圧縮の影響は最小限です。また、メッセージごとのキーで各メッセージを暗号化してから、このキーをキー暗号化キーで暗号化して転送します。これは、かなり一般的なことです（特に公開キー暗号が関係する場合）。 1つのキーの下で送信される暗号文の量を、圧縮をいじるよりもはるかに制御します。
次のポイントは、暗号化によって暗号文の長さをある程度隠すこともできます。パケットの長さと頻度を観察することによって、誰かがTLS接続で何をしているかについての「メタデータ」を得ることはそれほど難しくありません。暗号化の前に圧縮すると、「信号」の強度が低下する場合がありますが、トラフィック分析が心配な場合は、固定長へのパディングなどの他のことを行う必要があります。繰り返しますが、圧縮によって悪い状況が発生する可能性があります。少し悪いが、それは悪い状況を良い状況に変えるつもりはない。
最後に、TLSプロトコル内の圧縮がv1.3で廃止され禁止されると聞いたことがあるかもしれませんが、少なくとも私が最後にドラフトを読んだときはそうでした。これは一般的に圧縮とは関係ありませんが、TLS 1.2以前の標準で暗号化、パディング、MACおよび圧縮が相互作用する特定の方法にいくつかの脆弱性（CRIME、BEASTなど）があったためです。これは、より高い（アプリケーション）レベルで圧縮できないことや、一般的に圧縮が暗号化を弱めることを意味するのではなく、少なくとも実際の暗号化モジュールでは場所がなく、少なくともTLSで行われる方法ではありません瞬間。
編集
さらなる質問をするコメントへの応答として、圧縮がどのようにあなたを助けるか、または傷つけることができるかの2つの例はここにあります。
例1あなたは仕事に応募し、あなたが親友にそれを受け取ったかどうかを知らせる暗号化されたメッセージを送信することに同意します。 IT部門で作業するため、単純な「はい」または「いいえ」は機能しません。アニメーションGIFである必要があるため、yes.gifとno.gifの2つのファイルを用意します。誰かが見ているだけで心配です。あなたの暗号文のファイルサイズで、あなたはそれらを正確に64KBにします。しかし、yes.gifは色とポニーと虹でいっぱいで、圧縮すると60KB大きくなります-no.gifはより控えめな遅い白黒のアニメーションで、4KBに圧縮されます。暗号化プログラムは、暗号化の前に自動的に圧縮を適用します。この場合、圧縮はセキュリティを完全に台無しにします。
例2アニメーションGIFをあきらめ、次回友達に会いたいときは、「次の[曜日に会いましょう]と言う暗号化された電子メールを彼に与えることに同意しました。 ]。 "暗号化プログラムは、8文字（64ビット）ブロックで暗号化します。メッセージが「次の月曜日に会いましょう」の場合。 「次の水曜日に会いましょう」であれば、3つのブロックにうまく収まります。それは4ブロックです。もう一度失敗しました。この場合、すべての日を最初の3文字に「精神的に圧縮」する（「次の水曜日に会いましょう」）と、救われます。
要約すると、圧縮は一般的に暗号化を助けたり害したりすることはありません。通常、長さが類似しているがエントロピー/圧縮性のレベルが異なるメッセージを処理する必要がある場合は、効果よりも害が大きい可能性があります。
CRIME攻撃は、圧縮を1つの要素として含む非常に特殊な状況のために機能しますが、ファイルストレージには適用できません。
圧縮はセキュリティではありません。 steganography data hiding と圧縮を混同している可能性がありますが、いずれにせよ、どちらも真のセキュリティを提供するのではなく、単に物事を隠すだけです。もちろん暗号化はあなたのデータを保護します。
Wiki から：
エンコードするデータを難読化することにより、ブルートフォース攻撃の効果を弱めることができます。これにより、攻撃者がコードをクラックしたことを攻撃者が認識しにくくなります。暗号化システムの強さの尺度の1つは、攻撃者が理論的に攻撃システムにブルートフォース攻撃を仕掛けるまでにかかる時間です。
これが混乱の始まりかもしれません。 'winzipを使用して hex data を見ると、すべてが違って見えます。したがって、ぼんやりとした小さなレイヤーを作成しましたよね？'Wrong！nique不明瞭な方法を使用している場合を除いて、実行しているのは、めちゃくちゃ短い時間。
これは、すべてのファイルに ファイルシグネチャ と呼ばれるものが含まれるため（オペレーティングシステムがすべてのデータを理解できるようにするため）、独自の一意のファイルシグネチャを作成するか、他のデータ内でデータを非表示にしない限り署名ある署名を別の署名に変更するだけで得られる拡張機能はありません。
非常に刺激的な名前を持つ複数の攻撃は、圧縮がプレーンテキストに関する情報を漏らすことによって脆弱性を引き起こすことができることを示しました：
- CRIME（圧縮率の情報漏えいが容易になりました）
- BREACH（ハイパーテキストの適応圧縮によるブラウザの偵察と引き出し）
基本的に、平文の一部を制御できる場合は、暗号文のサイズを確認することで平文の他の部分を推測できます（平文の既存のパターンに一致させると圧縮がより効果的になるため）。