圧縮してから暗号化、またはその逆ですか？

私は、ネット上のトラフィックを暗号化する（AES256）VPNシステムを書いています（すでに他に1,000,001人がいるのに自分で書くのはなぜでしょうか？

基本的には、あなたの考えを実行して、正しい順序でこれを行うようにします。

現時点では、パケットは送信前に暗号化されていますが、ある程度の圧縮を追加して、データの転送を少し最適化したいと思います。重度の圧縮ではありません-常にCPUを最大限に使いたくはありませんが、圧縮が可能な限り効率的になるようにします。

だから、私の考えでは、暗号化されていないパケットは暗号化されたパケットよりも圧縮されるため、暗号化する前にパケットを圧縮する必要がありますか？またはその逆ですか？

おそらく圧縮にはzlibを使用するでしょう。

詳細については、スーパーユーザーブログをご覧ください。

暗号化が適切に行われた場合、結果は基本的にランダムなデータになります。ほとんどの圧縮スキームは、何らかの方法で除外できるデータのパターンを見つけることで機能しますが、暗号化のおかげで現在は何もありません。データは完全に非圧縮性です。

暗号化する前に圧縮します。

暗号化の前に圧縮します。圧縮されたデータは、ソースデータのわずかな変更によって大きく変化する可能性があるため、差分暗号解析を実行することは非常に困難です。

また、Mr.Alphaが指摘しているように、最初に暗号化した場合、結果を圧縮するのは非常に困難です。

特定のユースケースに依存する場合でも、Encrypt-then-Compressをお勧めします。そうしないと、攻撃者は暗号化されたブロックの数から情報を漏らす可能性があります。

ユーザーがサーバーにメッセージを送信し、攻撃者が（javascriptなどを使用して）送信する前にユーザーメッセージにテキストを追加する可能性があると想定します。ユーザーは、適切なデータをサーバーに送信し、攻撃者はこのデータを取得したいと考えています。そのため、ユーザーがサーバーに送信するデータに異なるメッセージを追加しようとすることができます。次に、ユーザーは自分のメッセージと攻撃者からの追加テキストを圧縮します。DEFLATE LZ77圧縮を想定しているため、関数は同じ情報を最初の外観へのポインターに置き換えます。したがって、攻撃者がホールプレーンテキストを再現できる場合、圧縮機能はプレーンテキストのサイズを元のサイズとポインターに縮小します。暗号化後、攻撃者は暗号ブロックの数を数えることができるため、追加されたデータがユーザーがサーバーに送信したデータと同じかどうかを確認できます。このケースは少し構築されているように聞こえますが、TLSの重大なセキュリティ問題です。この考え方は、セッションを盗むためにTLS接続でCookieをリークするCRIMEと呼ばれる攻撃で使用されます。

出典：http : //www.ekoparty.org/archive/2012/CRIME_ekoparty2012.pdf

私の見解では、メッセージを圧縮すると低次元に投影されるため、ビット数が少なくなります。つまり、圧縮されたメッセージ（ロスレス圧縮を前提とする）は同じビット数の情報を持ちます（削除したものは冗長でした！ ）したがって、ビットあたりの情報が多くなり、結果としてビットあたりのエントロピーが増えますが、メッセージが圧縮されなかったときと同じ合計エントロピーになります。さて、ランダム性は別の問題であり、圧縮のパターンがモンキーレンチを投げることができる場所です。

暗号化の前に圧縮を行う必要があります。ユーザーはデータの転送を待つことに時間を費やしたくありませんが、時間を無駄にせずにすぐにそれを行う必要があります。

前に指摘した暗号化前の圧縮。圧縮は、圧縮できる構造を探します。暗号化は、構造が検出されないようにデータをスクランブルします。最初に圧縮することにより、ファイルが小さくなり、転送するペイロードが少なくなります。暗号化は、圧縮されているかどうかに関係なく機能しますが、前述したように、圧縮ファイルで差分暗号化分析を実行することはさらに困難です。

圧縮により、情報エントロピーが削減されます。最大圧縮によりエントロピーが最小になります。完全に暗号化されたデータ（ノイズ）の場合、最大エントロピーと最小エントロピーは同じです。