私は、ネット上のトラフィックを暗号化(AES256)するVPNシステムを書いています(すでに100万001ものVPNがあるのに、なぜ私のものを書くのでしょうか?まあ、私のは他のどのVPNシステムにも当てはまらない特定のタスクのための特別なものですが）。)
基本的には、自分の考えが正しいかどうかを確認するために、あなたの前で考えを巡らせたいと思っています
今のところ、パケットは送信前に暗号化されているだけですが、データの転送を少し最適化するために、ある程度のレベルの圧縮を追加したいと思っています。重い圧縮ではありません – CPUを常に最大にしたくはありませんが、圧縮が可能な限り効率的になるようにしたいのです
つまり、暗号化する前にパケットを圧縮した方が暗号化されたものよりも圧縮されていないものの方が良いのではないかと考えています。それともその逆かな？
おそらく圧縮にはzlibを使うことになると思います
続きを読む スーパーユーザーブログに掲載されています
88 Majenko 2011-03-15
暗号化が適切に行われていれば、結果は基本的にランダムなデータになります。ほとんどの圧縮方式は、データのパターンを見つけることによって動作しますが、暗号化のおかげで今は何もありません
暗号化する前に圧縮します
177 Mr Alpha 2011-03-15
暗号化する前に圧縮します。圧縮されたデータは、ソースデータのわずかな変化に対して大きく変化する可能性があるため、差分暗号解析を行うことが非常に困難になります
また、αさんが指摘しているように、先に暗号化してしまうと、結果的に圧縮するのが非常に難しくなります
22 Juancho 2011-03-15
特定のユースケースに依存するとしても、私は Encrypt-then-Compress をお勧めします。そうしないと、攻撃者は暗号化されたブロックの数から情報を漏らす可能性があります
サーバにメッセージを送信するユーザと、送信前にユーザのメッセージにテキストを追加できる攻撃者を想定しています。ユーザーはサーバーに何らかのデータを送りたいと考えており、攻撃者はそのデータを取得したいと考えています。そこで攻撃者は、ユーザーがサーバーに送信するデータに異なるメッセージを追加しようとすることができます。そして、ユーザは攻撃者からのメッセージと付加されたテキストを圧縮します。DEFLATE LZ77圧縮を想定しているので、この関数は同じ情報を最初の出現へのポインタに置き換えます。そのため、攻撃者が穴の開いた平文を再現できた場合、圧縮関数は平文のサイズを元のサイズに縮小し、そのポインタを表示します。そして、暗号化後、攻撃者は暗号ブロックの数をカウントすることができるので、自分が付加したデータが、ユーザーがサーバーに送ったデータと同じかどうかを確認することができます。このケースは少し構築的に聞こえるかもしれませんが、TLSのセキュリティ上の重大な問題です。このアイデアは、CRIMEと呼ばれる攻撃によって、セッションを盗むためにTLS接続でクッキーをリークするために使用されています
のソースを参照してください。http://www.ekoparty.org/archive/2012/CRIME_ekoparty2012.pdf
3 Tobias Braun 2014-01-14
私の考えでは、メッセージを圧縮すると、メッセージを低次元に投影するので、ビット数が少なくなり、圧縮されたメッセージ(ロスレス圧縮を前提とした場合)は、より少ないビット数で同じ情報を持っていることになります(削除したビットは冗長です！)。さて、ランダム性は別の問題であり、圧縮のパターンが猿のようなレンチを投げることができます
2 Prof 2012-10-09
圧縮は暗号化の前に行う必要があります。ユーザーはデータの転送を待つ時間を使いたくありませんが、時間を無駄にすることなくすぐに行う必要があります
1 sqlchild 2011-03-16
先に指摘されているように暗号化の前に圧縮。圧縮は圧縮できる構造を探します。暗号化は、構造が検出されないようにデータをスクランブル化します。最初に圧縮することで、ファイルが小さくなり、転送するペイロードが少なくなる可能性が高くなります。暗号化は、圧縮されているかどうかに関わらず仕事をしてくれますし、先ほども指摘したように、圧縮されたファイルで差分暗号解析を行うのはより困難になる可能性が高いです
1 Always Learning 2015-06-19
圧縮は情報のエントロピーを減少させます。最大圧縮はエントロピーを最小にします。完全に暗号化されたデータ（ノイズ）の場合、エントロピーの最大値と最小値は同じです
0 AbiusX 2011-03-16
