DeepCorrの相関手法は、すべてのTorユーザーの匿名化を解除できますか？
https://people.cs.umass.edu/~amir/papers/CCS18-DeepCorr.pdf
https://www.youtube.com/watch?v=_OKLtKgEn4k
この「Deepcorr」についていくつか質問があります。 「DeepCorr」は本当にうまく機能しますか？彼らは、「DeepCorrのパフォーマンスはテストフローの数で低下しない」と言いますが、Torを使用する人が増えるにつれて、同じサイズのWebサイト（単純なWebサイトが多い）を同時に閲覧する人が増えています。他のフローに同様の機能がある場合に、サイズとタイミングのみを使用してトラフィックのソース？
彼らは、10,000回線を使用して50,000サイト（Alexaのトップサイト）を閲覧し、各回線が50サイトを閲覧し、Torブラウザーの代わりに通常のFirefoxブラウザーも使用したと述べています。それが彼らにとってとてもうまくいった理由なのでしょうか？ Firefoxは、広告やCookieなどの理由でTorブラウザが生成しない特別なトラフィックを生成したのでしょうか？
この攻撃は隠しサービス（バージョン3）に対しても機能しますか？
DeepCorrの相関手法は、すべてのTorユーザーの匿名化を解除できますか？
いいえ、匿名化できません [〜＃〜] all [〜＃〜] Torユーザー。
（ただし、匿名化を成功させるために範囲を大幅に絞り込みます）
なぜ、そしてフロー相関攻撃とは
フロー相関攻撃は、攻撃者がさまざまなネットワークロケーションでネットワークフローを傍受する攻撃 "数学統計または機械学習手法（ニューラルネットワークなど）を使用してそれらを関連付けます。
DeepCorrの設定は、ネットワークから構成されます。 "Mの入力フローとNの出力フロー"：DeepCorrは入力フローをリッスンし、一端のユーザーのグループに近く、それだけでトラフィックが別の端で回線を出始めた瞬間を把握しようとします。そして、それは「ゴッチャ」を意味します！
ウェブサイト！=フロー
他のフローに同様の機能がある場合に、サイズとタイミングのみを使用してトラフィックのソースをどのようにして知ることができるでしょうか？
DeepCorrはしないしない Webサイトフィンガープリントを行います（これは、この記事で述べた別のクラスの攻撃です）、単に「フローA 「ネットワークの2つの異なるポイントで「フローB」に。
ウェブサイトの類似性は相関の成功には関係ありません。DeepCorrは、サイズ、時間、フロー方向（イン/アウト）などの小さなパケットシーケンスの機能で動作します。
まだ...
相関！=匿名化
記事 から：
フロー相関を実行できるようにするには、攻撃者はTorネットワークに出入りするフローの一部を観察（つまり、インターセプト）する必要があります。敵対者はそして特定のTor接続を匿名化解除できます...
「匿名化はできないかもしれません」と言いますが、フロー相関攻撃が成功しても、匿名化が成功するわけではありません。相関とは、「これらのユーザーがこれらのサイトのグループにアクセスした」ことを意味します（ただし、ユーザーのセットを大幅に絞り込み、匿名化の可能性を高めます）。
Firefoxは追加のパターンを生成しますか？
それが彼らにとってとてもうまくいった理由なのでしょうか？ Firefoxは、Torブラウザーが広告やCookieなどのために生成しない特別なトラフィックを生成した可能性があります。
私の意見では、TorとFirefoxのトラフィックフローに大きな違いはありません。
例：google.com
Firefox:
25 requests
1.31 MB / 677.67 KB transferred
Tor:
19 requests
1.39 MB / 498.30 KB transferred
直感的には、どちらのブラウザーもフローのユニークなパターンをいくつか生成し、そのWebサイト！=フローを忘れないでください。
また、DeepCorrは測定するのにあまり多くのトラフィックを必要としないようです。
「相関フローは、すべてのシステムで300パケット長です」...
Torの隠されたサービス
この攻撃は hidden services （version 3）に対しても機能しますか？
" why not "：DeepCorrはトラフィックフローに対して実行し、フローが「非表示」であるかどうかを気にしません。非表示のサービスは単なる別のトラフィックフローです。 DeepCorrは入力と出力を相互に関連付けます。
PS：可能な対策について一言。
対策
著者が述べたように：
「私たちの結果は、（パブリック）Torリレーが、 obfs4のようなトラフィックの難読化メカニズムをIAT = 1 で展開して、DeepCorrのような高度なフロー相関手法に抵抗する必要があることを示唆しています。」
（IAT = 0は役に立ちません）
「しかし、これはコストの増加、オーバーヘッド（帯域幅とCPU）の増加、およびそのような難読化メカニズムによって課せられるQoSの削減により、簡単な解決策ではありません...パフォーマンスの適切なバランスをとるTorに合わせた難読化メカニズムの設計、コスト、匿名性は、将来の作業のための困難な問題であり続けます。 "
私はそれらの方法がユーザーを識別するのに役立つとは思わない、私はフロー相関手法に焦点を当て、なぜそれを実現することが不可能であるのかを説明します（もちろん、ユースケースを調整して作成し、それを可能にすることはできますが、インターネット）。
一般に、現在のすべての通信は暗号化にTLSを使用しており、torも同じで、HTTP 1.1を使用しています。 HTTP 1.1では、いくつかの要求と応答が同じフローで行われます。つまり、（TCP Pushフラグもチェックして）アップストリームpdusの量とダウンストリームを相関させる必要があります。たとえば、 、2つのURLにアクセスして2つの画像をダウンロードするpython scryptを作成すると、システムは次のようなフロー特性のベクトルを生成できます。
[{"upstream_bytes": 500, "downstream_bytes": 5000},
{"upstream_bytes": 400, "downstream_bytes": 4000}]
最初のリクエストでは、アップストリームで暗号化された500バイトのデータが生成され、ダウンストリームで5000バイトの暗号化データが受信されます。2番目のリクエストでは、400アップと4000アップです。
この最小限のシナリオと、ブラウザーが異なる要求サイズを生成することを考慮に入れると、おそらくほとんどのブラウザーは、最初の要求（index.html）に対して、バイトに多少の差異がある同様の最初の要求パターンを生成します。
したがって、同じサービスにアクセスする複数のユーザーは、
[{"upstream_bytes": (500, 600), "downstream_bytes": (5000, 5500)},
{"upstream_bytes": (390, 420) "downstream_bytes": (4000, 4300)}]
アップストリームとダウンストリームは、ブラウザやTLSで行われた暗号化などの要素によって異なります。
そのため、宛先サイトにもphpのサポートがあり、他のユーザーグループがindex.phpにアクセスできる場合、ベクトルが同じである可能性が高くなります。これは、機械学習や他のテクノロジーを使用しても、フローの内部にあるものをゲスト化して相関をさらに不可能にすることを意味します。作成できる唯一のフロー相関は、（上流と下流の）ベクトルを他のフローの他のベクトルと比較し、統計でそれらを比較することです。ネットワーク（ユーザーとサーバー）を制御できるテストシナリオでは、検出のためのノイズを生成する可能性のある他のトラフィックがないため、おそらく簡単に推測できます。
すべてが同じサイズのPDFドキュメントを提供するだけの宛先サーバーでも考える場合、これにより、そのサービスを使用するすべてのユーザーに同じトラフィック分布が与えられ、コンテンツを知ることができなくなります。
一方、最近のブラウザは同じサイトに複数のネットワークフローを生成するため、これをさらに難しくしています。
一般的に紙はいいですし、いくつかの興味深いヒントがありますが、多くの研究論文、特に物事を検出し、出版するために結果を調整します。私はそれが事実であるとは言いませんが、少し疑わしいようです。結果は良好であり、データセットを公開しないため、他の研究者は自分たちが説明する手法を検証または改善できます。