Подозрительная информация о деанонимизации тор

Тут ранее обсуждали внесение задержек для "пакетов". Если правильно догадываюсь, Гость применял такой перевод для обозначения cell. Кстати и выполненый cooshoo перевод спецификации, также трактует cell как пакет. Думаю это не самый лучший вариант для cell. Потому как не всегда может быть понятно из дискуссии, какие именно "пакеты" нужно придерживать.
Это просто комментарий к прочитанному :>

Здесь часть дискутирующих (я, например), никогда не разбирались с протоколом основательно, чтобы вообще понимать что есть cell, и т.п. Просто высказываются общие соображения. Лично я имел в виду под пакетами некие пакеты tcp-сессии (типа тех, что ловит tcpdump).

Атака на корреляцию – это название класса атак, некоторые из которых могут быть чувствительны и к малым задержкам.

cell можно переводить словом "ячейка".

Кажется, сам Роджер где-то приводил такие формулы:

- Nb ( Nb – C – 1 ) If you are optimistic p = –––––––––––––––––––– N ( N – C – 1 ) Nb ( Nb – 1 ) If you are pessimistic p = –––––––––––––––––––– N ( N – C – 1 ) Nb = the number of bad nodes N = total number of nodes C = the circuit length

Подробнее здесь: EndToEnd attacks:

so if %20 of tor nodes belong to a single malicious entity, you have an approx %3.7 chance of using both entry and exit nodes from that entity in a three-nodes-circuit. If you are optimistic, the probability will be less if the circuit is larger than 3. If you are pessimistic, the shorter the circuit the better.

Первоисточник не помню. То ли из работы взято, то ли из обсуждения в рассылке, то ли из черновика спецификации.

Все предложения, обсуждаемые здесь в предыдущих нескольких страницах (увеличение длины цепочки, введение случайных задержек, смешивание путей) уже неоднократно обсуждались с разработчиками и были отвергнуты.

См. дискуссию с Ником Мэттьюсоном, там даны его ответы, ссылки на FAQ здесь и заодно здесь, на работы, в том числе на то как была полностью скомпрометирована сеть Crowd со случайно выбираемой длиной цепочек (один из предшественников проекта Tor).

Look into the predecessor attack against the Crowds system; the attacker doesn't need to know the circuit
length to guess whether a node is relaying or originating traffic.
<...>
I agree that if end-to-end correlation attacks were foiled, then we would want to look into other foiling other
attacks that are strictly harder than end-to-end correlation. But it isn't simply a matter of "adding random latency":
there have been many ways to "add random latency" analyzed in the research literature, and they're all either 1) not
effective enough to be worth it, or 2) so slow that you wouldn't be able to use Tor for TCP any more. These defences
are getting better, but we don't seem even close to something that would be a good idea to add to Tor.
<...>
figuring out how to do this kind of thing and analyzing whether it has
real benefit is the kind of design-intensive and-research-intenstive work that belongs on or-dev

Nick Mathewson

SATtva верно заметил выше:
У кого-то есть серьёзная теоретическая модель? Готовая оформленная работа с опровержением моделей из предыдущих работ? Без неё ваши предложения рассматривать не будут. У разрабов уже похоже аллергия на рандомизацию и длину цепочек.

Непродуманные предложения по рандомизации траффика, увеличению или случайному выбору длины цепочки – одни из самых распространённых наивных предложений по улучшению, которые судя по работам, были отвергнуты ещё когда Tor разрабатывался как закрытый проект.

Может что-то из этого будет реализовано позднее, при более высоком уровне теоретических проработок, но пока это ничего не улучшает, скорее наоборот.

Непродуманные предложения по рандомизации траффика, увеличению или случайному выбору длины цепочки – одни из самых распространённых наивных предложений по улучшению, которые судя по работам, были отвергнуты ещё когда Tor разрабатывался как закрытый проект.

Впрочем, по указанным же ссылкам:

Now, there is a good argument for making the number of hops in a path unpredictable. For example, somebody who happens to control the last two hops in your path still doesn't know who you are, but they know for sure which entry node you used. Choosing path length from, say, a geometric distribution will turn this into a statistical attack, which seems to be an improvement. On the other hand, a longer path length is bad for usability. We're not sure of the right trade-offs here. Please write a research paper that tells us what to do.

Видимо, проблема в том, что все лишь утверждают, что данные наивные улучшения не помогут анонимности. Однако, скурпулёзное изучение ранее опубликованных работ по теме и используемых в них моделей, доступно далеко не всякому из-за требования квалификации и/или времени. Было бы не дурно, если б кто-то на пальцах для непосвящённых объяснил, почему подобные предложения не улучшат тор. Что касается end-to-end атак, я вижу только один прямой аргумент: атака пересечения, которая быстро позволяет установить, общается ли A и B. Однако, только из этого не следует наивность всех предложений по {}.

пока это ничего не улучшает, скорее наоборот

И что же может ухудшить рандомизация очереди? А вот кое-что (при атаках, чуствительных к малым задержкам) улучшить может.

If you are optimistic, the probability will be less if the circuit is larger than 3. If you are pessimistic, the shorter the circuit the better

Судя по этому высказыванию, противники удлиннения цепочек – пессимисты. :)
А как пессимисты, они должны учитывать возможность сотрудничества авторов Tor c властями, чем и может объясняться их нежелание усиливать защиту Tor. :(

c властями

Которыми? Из: Великобритания, США, Австрия, Германия. Может кого-то пропустил, но для начала сойдет. Выбирайте? Люди из этих стран, являются разработчиками на полный рабочий день. Средства на оплату их труда идут из фонда НКО "Тор Проект".
У вас есть ссылки на научные статьи или исследовательские работы, которые решали бы описанные ранее в этом топике задачи, и которые разработчики намеренно игнорируют?

Которыми?

Надгосударственными, глобальными (кстати, управляют, в том числе и через НКО)

У вас есть ссылки

Пока что только подозрения.

Было бы не дурно, если б кто-то на пальцах для непосвящённых объяснил, почему подобные предложения не улучшат тор. Что касается end-to-end атак, я вижу только один прямой аргумент: атака пересечения, которая быстро позволяет установить, общается ли A и B. Однако, только из этого не следует наивность всех предложений по{}.

Так Мэтьюсон буквально на пальцах и объяснил почему следует. Атака end-to-end – самая эффективная. Если невозможно защититься от неё (а в сетях типа Tor это так и есть), то и от всех остальных, которые гораздо более затратны защищаться смысла нет.

Рандомизация, удлинение цепочек пока реально могут защитить против менее эффективных атак, с менее эффективным результатом, при неисследованных до конца теоретических параметрах и при сложностях в реализации при скоростных соединениях.

С другой стороны, удлинение цепочек, смешивание потоков приведёт к тому, что tor-трафик пройдёт через большее число узлов. Реально анонимность это не повысит, а число точек съёма трафика увеличит.

Скорее всего, многие просто думают по аналогии с почтой (римэйлерами), где все письма делятся на пакеты перемешиваются и задерживаются сутками, иои рэндомно или по мере накопления пула. Вот там никакой статистический анализ практически невозможен и даже защита от глобального наблюдателя практически гарантирована, и там чем больше длина цепочки, тем лучше (хотя потеря пакетов и время доставки тоже снижаются). Но когда проектируется сеть типа Tor – с TCP-соединением реального времени и интерактивными протоколами, она изначально не может иметь таких свойств анонимности и проектировать её надо по другому.

И что же может ухудшить рандомизация очереди? А вот кое-что (при атаках, чуствительных к малым задержкам) улучшить может.

Ну скачали с сети 1.5 Mb за 3 мин с характерными распределениями по времени, а на другом конце примерно таже картинка трафика, только более смазанная и огрублённая по размерам пакетов. Не нужны там точности до малых задержек. Ну соберут 1000 образцов вместо 10 для достоверной корреляции. Наверняка авторы (и не они одни) модели строили и считали более точные цифры и поняли, что это всё неэфективно.

У вас есть ссылки

Пока что только подозрения.

В открытых исследованиях хорошо бы сначала разобраться, а потом строить подозрения насчёт того, что якобы скрывают.

скачали с сети 1.5 Mb за 3 мин

А если чат (с репликами по 100 байт раз в минуту), да ещё оба сидят в крупных локальных сетях?

По поводу такого узкого канала как чат не знаю, но на обычном просмотре страниц с графикой (даже не мегабайтной) это уже неэффективно.

Также надо учитывать, что активный end-to-end атакующий может сам вносить задержки в трафик или портить пакеты и смотреть на изменение статистики на другом конце.

По моему качать и чатить можно считать разными классами задач. Поскольку траффик чата невелик, вполне реально построить специально чатовую анонимизирующую сеть (или добавить соответствующий режим в Tor) с гораздо лучшими показателями анонимности, например используя непрерывный покрывающий траффик.

По поводу гвардов-шпионов, без них всё равно хуже:

Tor path spec.

См. пункт "5. Guard nodes"

Here's the risk: if we choose entry and

exit nodes at random, and an attacker controls C out of N servers
(ignoring advertised bandwidth), then the
attacker will control the entry and exit node of any given circuit with
probability (C/N)^2. But as we make many different circuits over time,
then the probability that the attacker will see a sample of about (C/N)^2
of our traffic goes to 1. Since statistical sampling works, the attacker
can be sure of learning a profile of our behavior.

If, on the other hand, we picked an entry node and held it fixed, we would
have probability C/N of choosing a bad entry and being profiled, and
probability (N-C)/N of choosing a good entry and not being profiled.

По поводу чатов. Сеть tor – универсальный транспорт для TCP, но скорее с прицелом на браузинг. Стоит ли усложнять протокол для любителей чатов? Может для них наоборот покрывающий трафик не нужен из-за узкого канала?. Кому-то может нужны скрытые форумы или особые режимы для покрывания трафика из Tor в римэйлеры или ещё что. Будут ли это всё вносить в протокол? Как управлять включением-отключением этих опций?

Стоит ли усложнять протокол для любителей чатов?

Вероятно не стоит, вероятно лучше под каждую из задач (чат, броузинг, файлообмен,...) иметь свою специально заточенную программу, просто можно было-бы объединять их в один дистрибутивный комплект.
Касаемо чата кажется реальным сделать защиту и от глобального наблюдателя.