圧縮してから暗号化しますか、またはその逆ですか？
私は、ネットワーク全体のトラフィックを暗号化（AES256）するVPNシステムを書いています（すでに他に1,000,001人がいるのに、なぜ自分のものを書くのですか？さて、私のものは、他のどれにも当てはまらない特定のタスクのための特別なものです）。
基本的に私はあなたの前に私の考えを実行して、私がこれを正しい順序で行っていることを確認したいと思います。
現時点では、パケットは送信される前に暗号化されていますが、データの転送を少し最適化するために、ある程度の圧縮を追加したいと考えています。重い圧縮ではありません-常にCPUを使い尽くしたくありませんが、圧縮が可能な限り効率的になるようにしたいと思います。
だから、私の考えでは、暗号化されていないパケットは暗号化されたパケットよりも圧縮されるので、暗号化する前にパケットを圧縮する必要がありますまたはその逆ですか？
圧縮にはおそらくzlibを使用します。
続きを読む スーパーユーザーブログ 。
暗号化が正しく行われている場合結果は基本的にランダムなデータです。ほとんどの圧縮スキームは、何らかの方法で取り除かれる可能性のあるデータ内のパターンを見つけることによって機能しますが、暗号化のおかげで、現在はありません。データは完全に圧縮できません。
暗号化する前に圧縮してください。
暗号化する前に圧縮します。圧縮されたデータは、ソースデータの小さな変更によってかなり変動する可能性があるため、差分暗号解読を実行することが非常に困難になります。
また、Mr.Alphaが指摘しているように、最初に暗号化すると、結果を圧縮することが非常に困難になります。
特定のユースケースに依存する場合でも、暗号化してから圧縮することをお勧めします。それ以外の場合、攻撃者は暗号化されたブロックの数から情報を漏洩する可能性があります。
ユーザーがサーバーにメッセージを送信し、攻撃者が（javascriptなどを介して）送信する前にユーザーメッセージにテキストを追加できる可能性があると想定します。ユーザーがサーバーに機密データを送信し、攻撃者がこのデータを取得したいと考えています。そのため、ユーザーがサーバーに送信するデータにさまざまなメッセージを追加することができます。次に、ユーザーはメッセージと攻撃者からの追加テキストを圧縮します。 DEFLATE LZ77圧縮を想定しているため、関数は同じ情報を初出のポインタに置き換えます。したがって、攻撃者が穴の平文を再現できる場合、圧縮機能は平文のサイズを元のサイズとポインタに縮小します。暗号化後、攻撃者は暗号ブロックの数を数えることができるため、ユーザーが追加したデータがユーザーがサーバーに送信したデータと同じであるかどうかを確認できます。このケースは少し構成的に聞こえますが、TLSの深刻なセキュリティ問題です。このアイデアは、セッションを盗むためにTLS接続でCookieをリークするためにCRIMEと呼ばれる攻撃によって使用されます。
ソース： http://www.ekoparty.org/archive/2012/CRIME_ekoparty2012.pdf
私の見解では、メッセージを圧縮すると低次元に投影されるため、ビットが少なくなります。つまり、圧縮されたメッセージ（ロスレス圧縮を想定）は、少ないビットで同じ情報を持っています（削除したメッセージは冗長でした）。 ）したがって、ビットあたりの情報が多くなり、結果としてビットあたりのエントロピーが多くなりますが、メッセージが圧縮されなかったときと同じ合計エントロピーになります。さて、ランダム性は別の問題であり、それは圧縮のパターンがモンキーレンチを投げることができるところです。
先に指摘したように、暗号化前の圧縮。圧縮は、圧縮できる構造を探します。暗号化は、構造が検出されないようにデータをスクランブルします。最初に圧縮すると、ファイルが小さくなり、転送するペイロードが少なくなる可能性が高くなります。暗号化は、圧縮されているかどうかに関係なく機能します。前述のとおり、圧縮されたファイルに対して差分暗号解読を実行するのはより困難です。
暗号化の前に圧縮を行う必要があります。ユーザーはデータの転送を待つ時間を費やしたくないが、時間を無駄にせずにすぐに実行する必要がある。
圧縮により、情報エントロピーが減少します。最大圧縮はエントロピーを最小にします。完全に暗号化されたデータ（ノイズ）の場合、最大エントロピーと最小エントロピーは同じです。