Простой способ атаки "в обход" tor

Кстати, вот что неправильно:
Пусть было 100 узлов, стало 50 и из них половина поменяла свои ключи:
тогда C=50/100=0.5
D = 25 / 50 = 0.5
S=0.5/0.5=1, что совсем нехорошо.

О! Предвосхитили :) Зря объяснял.

Надо: если C=>1, то S=C/D, если C<1, то S=C*D
Т.е. для S и увеличение больше 1 и стремление к нулю будет свидетельствовать о нестабильности. А D считать как D = (I+1)/(I_max+1), чтобы никогда не равно было нулю.

Ужас! Так, срочно учим математику. У нас есть 2 случайных величины. Для простоты забъём на то, зависимы они или нет. Нам нужен случай, когда обе из них отклоняются не сильно от некоего среднего. Вводим стандартное отклонение и используем МНК.
Поскольку

C меняется от 0 до inf (в идеале равно 1), D от нуля до 1 (в идеале равно 1).

Поучаем: S(pinore) = (C – 1)^^2 + (D – 1)^^2.
В идеале таким образом определённое S будет стремиться к нулю в случае стабильной сети. И чем оно больше, тем нестабильнее сеть.

Вики меня не правильно поняло, имелось в виду ^ а не ^^ (я думал оно так их напишет сверху, как и подобает степеням тому быть).

Thanks Roger. We continue a discussion on our site and our minds is overheat :-)

Вроде только я пил, у вас-то почему мнения перегреты?

Проверяйте, особое внимание обратите на формулы, надеюсь ничего там не попутал (Nk+1 я заменил на Nk-1: всё-таки будущего статуса у пользователя никак не может быть, а предыдущий может храниться).

Всё-таки фиксим формулы с учётом того, что должны равняться не на предыдущий шаг а не некую предполагаемую среднюю статистику. Подробнее я описал раньше что это такое и зачем нужно.

Написать утилиту которая реализует указанный алгоритм по оффлайновой статистикие? Несложно.

И чё, привязываться к изменениям файлов статистики? Как мониторить-та? Или как дибилы-программеры мониторить "не появилось ли что нового" обращаясь к файлу каждые n секунд?
Сразу скажу что я дилетант в прогерстве, но мои представления таковы что без интеграции с самим клиентом по уму это не реализовать.

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

С посылом согласен.

Вообще, ygrek в рамках рассматриваемой модели сказал всё важное и по-существу – я согласен (сразу видно, что человек с образованием). Только модель осталось пофиксить, ибо сранивнение двух соседних шагов по времени ничего не даст, нужно сравнивать каждый шаг(t=t1) с одной и той же средней статистикой при t=0 (с шагом(t=0)). Я в своё время об этом пол дня думал, тоже не сразу догадался что срагивать соседние шаги коряво.

А время строго не определено. Да, за уши притянутая, чтобы было просто видно отклонение. Чтобы выделить ситуацию с уменьшением числа нод. Хотя главное значение имеет изменение только числа ключей.

В общем, не буду вдаваться в подробности, но можно показать, что замечание ygrek'а по этому поводу имеет смысл (ломает думать над контрпримером, когда ваше определение съежит, а вот его определение будет физичным).

если коллеги не против, можно отправлять.

Коллеги против. Предлагаю убирать свои сравнения статистики между двумя соседними моментами времени и мерить отклонение от некоего, приятого за среднего. Среднее апгрейдить лишь равняясь на дианмику статистики у других пользователей. Иначе между шагами k и k+1 далем выпрыскивание новых нод, какое бы не превысило срабатывание защиты программы, потмо такое же впрыскимвание делаем между шагами k+1 и k+2, и всё... "схема пошла в разнос".
С формулами пока сильно не мудрите – берите базовые отклонения:
inStability = (C? 1)^2 + (D? 1)^2, где C и D на k-том шаге по времени считаются не относительно шага k-1 а относительно шага k=1 (трастед-статистика, она же средняя).

На самом деле, смысл формализации далеко не очевиден из текста. Может и правда "своими словами"?

И так, и так. Помните, что всё правильное всегда выглядит просто и описывается простыми формулами. Если начинается перегруз обозначений, значит далеки от истины (формулы не те).
Имхо, здесь максимум 3-4 формулы надо-то...

т.к. не планировалось сравнивать состояния из разных источников в один промежуток времени

А формулы должны быть такими, чтобы они допускали такое сравнение, как и сторонняя утилита. Только тогда можно понимать что за метрику мы определили на множестве состояний и что мы сраниваем. Ну никакой культуры! Математически мы делаем очень простую вещь. У нас есть множество статистик (файлов статистики). Мы вводим метрику (это даст "расстояние" на мат. языке) между двумя статистиками. Расстояние – это такая функция, которая принимает два аргумента (две статистики) и возвращаем нам число. Вспоминаем, что расстояние в векторном пространстве, это функция которая каждым двум векторам сопоставляет число – расстояние между ними.

P. S.: в общем, вроде уже почти все ошибки совершены, на все грабли наступили, так что теперь можно формировать итоговое. Мои мысли вкратце сводятся к тому что

• Пишем правильную формулу для S.
• Вводим измерение относительно нулевого момента времени (средней (доверяемой) статистики).

Я ушёл спать, смогу ответить ещё что-нибудь уже только вечером.

Вики меня не правильно поняло, имелось в виду ^ а не ^^ (я думал оно так их напишет сверху, как и подобает степеням тому быть).

Тогда надо так: x^^2^^.

Thanks Roger. We continue a discussion on our site and our minds is overheat :-)

Вроде только я пил, у вас-то почему мнения перегреты?

s/minds/heads/ (или brains), но, на мой взгляд, это не принципиально. И если есть замечания к переводу, критикуйте, пожалуйста, последнюю версию перевода, а не первую.

И чё, привязываться к изменениям файлов статистики? Как мониторить-та? Или как дибилы-программеры мониторить "не появилось ли что нового" обращаясь к файлу каждые n секунд?

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

нужно сравнивать каждый шаг(t=t1) с одной и той же средней статистикой при t=0 (с шагом(t=0))

Тогда, наверное, t=t_n.

Ужас! Так, срочно учим математику. У нас есть 2 случайных величины. Для простоты забъём на то, зависимы они или нет. Нам нужен случай, когда обе из них отклоняются не сильно от некоего среднего. Вводим стандартное отклонение и используем МНК.

Да я понимаю к чему Вы spinore и ygrek клоните, вы хотите получить красивый нормированный и симметричный критерий, который бы укладывался в "правило трёх сигм" (нам бы одной хватило для 90% вероятности) и т.д. Как будто сеть стабильна хотя бы в некотором временном интервале и есть некоторый критерий, по которому пользователи не должны сильно отклоняться.

Во-первых, я не уверен вообще может ли он существовать и будет ли он иметь смысл.
Можно ли будет доказать, что он показывает оптимальным образом все атаки?

Во-вторых, я хотел применить другой подход: пользователи сравнивают показатель для одного и того же времени. Если у них (у всех) был скачок в одно и то же время, то скорее всего никакой атаки нет (или у них всё равно нет шансов её обнаружить путём нахождения различий). Далее могут статусы сравнивать. Кстати, статусы выдаются голосованием в V3 не чаще раз в 15 минут (про исключения не знаю).

Я не говорю, что мой подход лучше (может хуже): мы на разные аспекты упор делаем. Сравнение отклонения от некоего "правильного" значения или сравнение любого отклонения, которого у пользователя не было до этого и больше упор на синхронность его измений между пользователями.

C и D зависимы, если вы хотите их просто так считать по отдельности, то не проблема. C можно считать не только как изменение количества ключей, но и IP-адресов, имён.
Просто реально, есть разные случаи:

1. Число ключей осталось тем же. Но они поменялись почти все. Самый подозрительный случай.
2. Число ключей возросло. Если при этом число поменявшихся ключей примерно соответствует, то не так страшно. Похоже на ввод в сеть множества узлов. Но если оно при этом возросло раз в десять, есть вероятность соединиться с подставным узлом.
3. Число ключей резко упало. Это может быть массовый останов узлов (какие-нибудь проблемы с новой версией сервера, о чём предупреждал Роджер). Это не так серьёзно, но если нам дают слишком мало узлов для выбора, то это опять подозрительно.

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

т.к. не планировалось сравнивать состояния из разных источников в один промежуток времени

Неправильно выразился. Планировалось получить скачок между шагами, который был бы одинаков у пользователей в тот же промежуток времени.

По-моему письмо можно отправить и сейчас как есть – с описанием идеи. С чистого листа придумать "хороший" критерий мы всё равно не сможем (даже ориентируясь на математическую красоту) – нужна практическая проверка – это потребует много времени.
unknown, наверное вы правы, красивый идеальный критерий скорее всего работать не будет, т.к. мы имеем дело с неидеальным грубым реальным миром :) – но ведь интересно..
Хочется в общем посмотреть статистику сети, не обязательно с точки зрения этой атаки.

unknown, наверное вы правы, красивый идеальный критерий скорее всего работать не будет, т.к. мы имеем дело с неидеальным грубым реальным миром :) – но ведь интересно..
Хочется в общем посмотреть статистику сети, не обязательно с точки зрения этой атаки.

Мне тоже интересно, а статистику можно изучать, никто не мешает.

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

Возможно моя идея с одним критерием действительно неосуществима и порочна изначально.

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

Я не ставлю чёткий таймлайн (с идеальными критериями можно полгода провозиться), но хочется отправить то что есть (и так уже много).

Если что-то получится ещё, будет повод о себе напомнить и следующее письмо отправить.

Да я понимаю к чему Вы spinore и ygrek клоните, вы хотите получить красивый нормированный и симметричный критерий, который бы укладывался в "правило трёх сигм" (нам бы одной хватило для 90% вероятности) и т.д. Как будто сеть стабильна хотя бы в некотором временном интервале и есть некоторый критерий, по которому пользователи не должны сильно отклоняться.

Я даже не знаю что есть критерий трёх сигм, но предполагаю что речь идёт о неравенстве Чебышева и вероятность отклонений больших трёх сигм. Собственное, речь не об этом. Мы можем всего лишь заменив одни формулы на другие существенно улучшить качество оценки – так почему бы это не сделать?!

Во-первых, я не уверен вообще может ли он существовать и будет ли он иметь смысл.
Можно ли будет доказать, что он показывает оптимальным образом все атаки?

Для начала, нужно получить список всех атак. Потом уже ставить подобный вопрос. Пока что я увидел только одно существенное нарекание в треде: куча нод систематически включается только на определённое время суток и т.д. Касаемое конеретно этого обстоятельства нужно просто оценить: куча – это сколько процентов? 50? 5? Если на фоне общего числа нод это не великое колебание, то проблем нет, всё решается лишь выставлением ограничителя на S, который бы допускал такие суточные изменения, но не пропускал бы атаки.

Во-вторых, я хотел применить другой подход: пользователи сравнивают показатель для одного и того же времени. Если у них (у всех) был скачок в одно и то же время, то скорее всего никакой атаки нет (или у них всё равно нет шансов её обнаружить путём нахождения различий). Далее могут статусы сравнивать. Кстати, статусы выдаются голосованием в V3 не чаще раз в 15 минут (про исключения не знаю).

Я не говорю, что мой подход лучше (может хуже): мы на разные аспекты упор делаем. Сравнение отклонения от некоего "правильного" значения или сравнение любого отклонения, которого у пользователя не было до этого и больше упор на синхронность его измений между пользователями.

Неправильно выразился. Планировалось получить скачок между шагами, который был бы одинаков у пользователей в тот же промежуток времени.

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

Вот... Только теперь-то я вас понял, могу уже конструктивно повозражать по поводу подходов :) Вы, unknown, смотрите на мониторинг этой атаки как на обычное исследование скорее, а не как на нечто, что тут же должно давать конкретный технический продукт защиты. Я же смотрю на неё скорее как практик которому нужна защита от неё и как можно скорее. В нейтральном анализе смысле различия между подходами вот каковы:
Вы включаете "дебаг-уровень отладки" статистики и пишете пошаговые сравнения. Вы надеетесь, что задним числом сравнив свою статистику (куча фйлов, так как они обновляются относительно часто) в соответствующие времена со статистикой соседа выясните правду. Во-первых, минусы:

• Реакция исключительно постфактум, но никогда не до.
• Слишком много файлов и объёмов данных, которые прийдётся сравнивать.
• Будет сложно найти кучу народа, кто согласился бы писать все скачки статистики втечение длительного промежутка времени, всего лишь ради одной-единственной атаки (а атак на тор кучу можно придумать).
• Поптыка синхронизовывать статистику с сстатистикой соседа влекёт за собой трудности (чё, будем каждые 15 минут друг с другом файлами статистики перекидываться?).

Вы уж меня извините, это может быть всполедствии включено как дополнительная мера "дебаг-уровня", но с практической точки зрения она пока мало чего не даёт. Мы должны думать во-первых о других и технической стороне дела, в идеале должна быть одна конопка которая будет загараться на атаку и справшивать у пользователя "что едлать? Идти или не идти дальше?" либо будет действовать в рамках заданных для неё ограничений. "Любите юзера", что называется :) Он должен выставить 2-3 разумных числа-переметра в конфиге и забыть про эту атаку – ему нужно пользоваться тор-сетью а не изучать статистики(!).

Теперь смотрим то что я предлагаю:

• Сравниаем друг с другом только среднюю статистику. Её можно сравнивать иногда, например раз в месяц (не думаю что за месяц сильно меняется число узлов в сети тор). При попытке мониторить атаку заранее нам уже не нужно каждые 15 минут обмениваться файлами статистики – достаточно раз в месяц этого сделать. А это уже куда легче технически.
• Когда происходит атака, я её могу засчеь в реальном времени и остановить программу, я её обнаруживаю до, а не после.
• Предложенная схема не сложнее вашей, но она уже технически дорабатываема до уровня конкретной реализации и будет реально давтаь разумную защиту при небольшом геморрое.

Поэтому я предлагаю начать с простого: сделаем сравнение с "трастед-средним", а уже потом будем смотреть на динамику (это что вы предлагаете).

Самый концептуальный момент – в том, что равняясь на среднее всегда самому уединённо видно, есть лиатака и что происходит с сетью, а равняясь на предыдущий шаг, видно лишь малое отклонение, из которого ничего толком заключить нельзя (ибо надо смотреть уже на совокупную динамику за массу предыдущих шагов по уму, я по сути предложил лишь упрощённый вариант – сравниваемся с начальным моментм времени). Вы поймите, что атака не обязательно есть марковский процесс (на шаге k всё ништяк а на шаге k+1 противник ввёл все свои фиктивные нод или что-то подобное), проивник может сделать её немарковской, и предполагая что вы включили защиту от неё заранее, постепенно впрыскивать ноды пока не доведёт вашу итоговую статистику до до уровня нужной для атаки (а поскольку в реальном времени вам не удобвно сравниться с сосдеями каждые 15 минут, вы вообще ничего не заметите. Я уж не говорю о том, насколько легко/трудно противнику будет понять, с кем вы сравниваете статистику а с кем нет, а то он может прдделывать её для группы связянных друг с другом пользователей).

Просто реально, есть разные случаи:
Число ключей осталось тем же. Но они поменялись почти все. Самый подозрительный случай.
Число ключей возросло. Если при этом число поменявшихся ключей примерно соответствует, то не так страшно. Похоже на ввод в сеть множества узлов. Но если оно при этом возросло раз в десять, есть вероятность соединиться с подставным узлом.
Число ключей резко упало. Это может быть массовый останов узлов (какие-нибудь проблемы с новой версией сервера, о чём предупреждал Роджер). Это не так серьёзно, но если нам дают слишком мало узлов для выбора, то это опять подозрительно.

Давайте ближе к Земле и практике:
Какая из этих атак не отлавливается посредством измерения S = (C – 1)² + (D-1)²?

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

Грамотное замечание, но всё начинается с деления общей задачи на часть независимых модулей. По моему мнению, указанное вами дополнение относится к дополнительной усложнённой атаке, и его слеждует рассматривать как второй шаге приближения к идеалу, а пока мы рассматриваем 1ый, и нам нужно 1ый шаг что можно сделать втолковать Роджеру.

По-моему письмо можно отправить и сейчас как есть? С описанием идеи. С чистого листа придумать "хороший" критерий мы всё равно не сможем (даже ориентируясь на математическую красоту)? Нужна практическая проверка? Это потребует много времени.

Чего бояться, дорабатываем до нормально состояния письмо с учётом поправок и отправляем. Предложив хотя бы что-то мы упрощаем задачу разработчикам тор. В добавке укажем: "Это наше предложение, может быть вы увидите ошибки в его конструкции и придумаете что-то своё, лучшее".

Возможно моя идея с одним критерием действительно неосуществима и порочна изначально.

Можно строго показать что почти для любой куйни достаточно одного числа для оценки и оно называется МНК. Самих величин может быть хоть миллиён (просто надо будет в общем случае понять как сконструировать правильные случайные величирны из того что наблюдаем а потом применить уже к ним МНК).

Spinore дело говорит. Средние всегда надёжнее чем значения случайных величин, в том числе и в динамике.

Тот метод, который предлагается, называется средним по скользящему окну (sliding window average).
Идея в том, что усредняются характеристики за время от T-dT до T, где dT-ширина окна. Такие методы применяются
также в техническом анализе (статистика рынков валют и акций). Метод работает потому, что в большом количестве случаев
системы эргодичны (т.е. среднее "по ансамблю" совпадает со "средним по времени").

Кроме того, spinore предлагает брать средние на нескольких временных масштабах (разных dT). Это связано с тем,
что система узлов сети Tor имеет несколько характерных времен (суточные колебания, и т.п.). Поэтому это тоже здравая идея.

Естественно константы (ширины окон, пороговые значения отклонений средних) надо выбирать аккуратно. Здесь место и для
теоретических исследований, и для экспериментов. Есть где unknown-у развернуться :)

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

Мы должны думать во-первых о других и технической стороне дела, в идеале должна быть одна конопка которая будет загараться на атаку и справшивать у пользователя "что едлать? Идти или не идти дальше?" либо будет действовать в рамках заданных для неё ограничений. "Любите юзера", что называется :) Он должен выставить 2-3 разумных числа-переметра в конфиге и забыть про эту атаку – ему нужно пользоваться тор-сетью а не изучать статистики(!).

spinore, Вы уже пытаетесь мне втолковать тоже, что и Роджер, я это понимаю прекрасно. Я согласен, это идеально было бы.

Но он высказал и свои сомнения по поводу этого: слишком чувствительные настройки – много ложных срабатываний, слишком грубые – можно пропустить атаку.

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

Тут важно то, что можно выявить "левые" ключи и после сравнения статусов от всех добровольцев за один период времени выявить у кого есть "левые" статусы и предъявить этот "обвинительный" документ как доказательство нечестности DA. Что-то вроде наблюдателя на выборах.

Ещё одно рабочее упрощение: атака проводится только за один шаг (максимум несколько). В расчёте, что "delayed partial cache poisoning" почти невозможен, если пользователь может на следующем шаге снова скачать правильный статус с правильного зеркала.

Ну допустим, две тысячи узлов. Противник вбросил или заменил 200 виртуальных фальшивых и "разместил" на них "более свежие статусы", в расчёте, что пользователь их скачает и в каждом новом статусе он будет заменять по только по двести узлов, а не все сразу.

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

Теперь смотрим то что я предлагаю:

• • Сравниаем друг с другом только среднюю статистику. Её можно сравнивать иногда, например раз в месяц (не думаю что за месяц сильно меняется число узлов в сети тор). При попытке мониторить атаку заранее нам уже не нужно каждые 15 минут обмениваться файлами статистики – достаточно раз в месяц этого сделать. А это уже куда легче технически.
  • Когда происходит атака, я её могу засчеь в реальном времени и остановить программу, я её обнаруживаю до, а не после.
  • Предложенная схема не сложнее вашей, но она уже технически дорабатываема до уровня конкретной реализации и будет реально давтаь разумную защиту при небольшом геморрое.

Поэтому я предлагаю начать с простого: сделаем сравнение с "трастед-средним", а уже потом будем смотреть на динамику (это что вы предлагаете).

Вот здесь у меня есть одно скептическое соображение, которое могут подтвердить только разработчики ну или мы сами путём долгих наблюдений. Понятно, что есть динамика, но я не верю, что trusted-среднее за любой разумный промежуток времени реально есть.

2 Vadim_Z, я об этом тоже подумал. Только в этом реально можно увязнуть.

Сеть tor статистически ближе к поведению толпы людей, а то что мы можем померить – это как биржевой курс. Мы посчитаем среднее, а он возьмёт и скакать начнёт, или обвалится, или офигенно стабилизируется в зависимости от чьих-то настроений или обстановки в мире. Завтра в Германии или где-то примут новый закон, все операторы перепугаются и куча нод отрубится. После завтра закон понаставят кучу новых нод с новой альфа-версий. После-после завтра в этой версии найдут баг, узлы отключаться, наши средние критерии опять уедут.

Давайте ближе к Земле и практике:
Какая из этих атак не отлавливается посредством измерения S = (C – 1)² + (D-1)²?

Да мне Ваш S чисто внешне больше нравится, я понимаю, что он формально более правильный, универсальный и в него при необходимости можно понапихать сколь угодно много параметров.

Не учесть таким универсальным способом, что когда C и D сильно скачут это плохо, но ещё хуже когда есть определённые корреляции между ними в этих скачках. Причём некоторые корреляции – "хорошие" или "смягчающие" друг друга (немного увеличилось число узлов, но и количество изменившихся ключей возросло на столько же, а если C и D одновременно в сторону уменьшения, то это ещё лучше, а снижение ниже некоторого предела – опять плохо, это вообще отдельный параметр должен быть), а некоторые корреляции "плохие" (если C и D ползут в разные стороны, то это хуже; уменьшение D – это в принципе хуже, чем увеличение C и т.д.).

Т.е. при разных соотношениях C и D мы имеем разные состояния системы. Причём смену IP адресов тоже надо учитывать (не знаю как).

Если вам ближе физические аналогии (тут меня можете смело поправить если слишком наивно): Вы пытаетесь просто рассмотреть все параметры, как независимые, не имеющие взаимосвязи или конкретного смысла.

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

Только, это также неблагодарно как считать прогноз экономический, политический, поведенческий когда все факторы работают только приблизительно.

СПАСИБО ВАН ЛЮДИ)) НО? Не могли бы вы сделать типа статистики? За-тор безопасен! Против-нетЯ и многие юзающие ТОР не так просветлены как многие тут! И очень много НАРОДУ желает всеж выслушать ВАШЕ мнение! Если есть подозрения то? КОМПЛЕКС МЕР по защите от знающих людей ТУТ бы не помешал бы я думаю)

Но он высказал и свои сомнения по поводу этого: слишком чувствительные настройки? Много ложных срабатываний, слишком грубые? Можно пропустить атаку.

Уже обсуждали много раз. Опция для параноиков, и после исследований средних и дисперсий возможно включим уже для всех. Для начала она в любом случае будет как для параноиков, какая бы она не была.

Я предлагаю паралелльную идею? Временно отказаться от построения реальной защиты и заменить её на коллективный аудит, основанный на сообществах заинтересованныхх пользователей

А нафига?? Если то что я предлагаю не сложнее, но зато сразу заземляется? А куда ваш аудит пришить? Кто этим будет заниматься? Ну и по сути, "случайная величина"... её ни к чему не пришить, и она легко обходится.

Тут важно то, что можно выявить "левые" ключи и после сравнения статусов от всех добровольцев за один период времени выявить у кого есть "левые" статусы и предъявить этот "обвинительный" документ как доказательство нечестности DA. Что-то вроде наблюдателя на выборах.

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

Ещё одно рабочее упрощение: атака проводится только за один шаг (максимум несколько). В расчёте, что "delayed partial cache poisoning" почти невозможен, если пользователь может на следующем шаге снова скачать правильный статус с правильного зеркала.

А что, delayed partial cache poisoning это что-то слишком экстраординароное? И покажите мне почему мой подход её не отловит, а то я это в упор не вижу. Повторяю – среднее апгрейдится время от времени мануально. Ща по пгп обращусь к тому кого знаю лично, попрошу запустить тор и скачать, или ещё чё-нить подобное сделаю. И буду изучать, действительно ли статистика за это время поменялась так как как мне предъявляет сервер.

Если кого ввёл в заблуждение, "средняя статистика" – это не усреднение в обычном смысле по статистикам. Это просто одна какая-то статистика, которую мы проверили по разным каналам и стали ей доверять. Правильнее было бы её называть доверяемой статистикой. Но посольку если бы мы знали истиное среднее в отсутствие ататки, можно было бы сравнивать с ним (но мы его не знаем и знать не будем), вот потому по аналогии я и гвоорю что "среднее". В письме лучше напистаь trasted конечно, чтобы не вводить никого в заблуждение.

Меня ещё поправили что S в моём опредлении не есть дисперися, а всего-навсего "отклонение" от trusted-статистики, которая по опр. полагается верной для t=0.

Ну допустим, две тысячи узлов. Противник вбросил или заменил 200 виртуальных фальшивых и "разместил" на них "более свежие статусы", в расчёте, что пользователь их скачает и в каждом новом статусе он будет заменять по только по двести узлов, а не все сразу.

Ну и почему мой метод не сработает? Изучим статистику и поймём праивльные коэффициенты которые в норме никогда не превышаются.

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

Нет, не обойдёт :) Пример в студию. Коэффициенты подбираются так, чтобы суточные колебания пропустить а атаку – нет.

Вот здесь у меня есть одно скептическое соображение, которое могут подтвердить только разработчики ну или мы сами путём долгих наблюдений. Понятно, что есть динамика, но я не верю, что trusted-среднее за любой разумный промежуток времени реально есть.

См. определение выше. Я очень аккуратно описал что я понимаю под этим термином в том посте где писал конфиг для, опираясь на моё понимание того ка как работает тор. Жалко, что никто внимательно тот пост вы не прочитали. Она не имеет прямого отношения с реальным средним по релаьной сети(!), потому что мы не можем гарантировать что "ататки не было".

Завтра в Германии или где-то примут новый закон, все операторы перепугаются и куча нод отрубится. После завтра закон понаставят кучу новых нод с новой альфа-версий. После-после завтра в этой версии найдут баг, узлы отключаться, наши средние критерии опять уедут.

И что? Я не думаю что сеть тор до такой степени нестабильна. Или под предлогом того что всё можно обойти, вообще опустим лапы и перестанем бороться?

Не учесть таким универсальным способом, что когда C и D сильно скачут это плохо, но ещё хуже когда есть определённые корреляции между ними в этих скачках. Причём некоторые корреляции ? "хорошие" или "смягчающие" друг друга (немного увеличилось число узлов, но и количество изменившихся ключей возросло на столько же, а если C и D одновременно в сторону уменьшения, то это ещё лучше, а снижение ниже некоторого предела? Опять плохо, это вообще отдельный параметр должен быть), а некоторые корреляции "плохие" (если C и D ползут в разные стороны, то это хуже; уменьшение D? Это в принципе хуже, чем увеличение C и т.д.).

Мы измеряем не корреляции, в вероятность атаки. Уклонение от trusted всё это прекрасно ловит.

Т.е. при разных соотношениях C и D мы имеем разные состояния системы. Причём смену IP адресов тоже надо учитывать (не знаю как).

Они физически разные, но с точки зрения вероятности атаки несут угрозу с одинаковой вероятностью.

Если вам ближе физические аналогии (тут меня можете смело поправить если слишком наивно): Вы пытаетесь просто рассмотреть все параметры, как независимые, не имеющие взаимосвязи или конкретного смысла.

ЦПТ и ЗБЧ ещё никто не отменял ©

Пока он ещё в процессе обсуждения :)

2 SATtva: мы должны прийти к единому выводу, тогда и приверим ещё раз ваше письмо на предмет как соответствия "физике", так и "языку". Пока я хочу успокоить unknown'а :) То ли я запутал всех своими терминами (сорри если что), то ли кто-то упорно тупит, не могу понять.

Ладно, я попытаюсь кратко просуммировать то что предлагал и попытаюсь использовать адекватные термины, чтоб без заблуждений:

• На данный момент мы не знаем реальных коэффициентов и реальной статистики, но предположим что наш метод работает. Сразу оговариваюсь что будет оставлено за кадром на будущие доработки впоследствии, и что обсуждаться не будет:
  • Искусственное введение нод в оффлан.
  • Суточные колебания (предполагаем что сеть однородна по времени)
• Вначале мы скачиваем свою самую первую статистику с тора, и изучаем её на предмет отличия от статистики, которую скачали запустив свой тор-клиент наши соседи. Пытаемся добыть статистику разными путями и сраниваем её. Если анонмальных отклонений между статистиками не обнаружено, запускаем тор. Называем таким образом назначенную статистику трастед-статистикой, и полагаем её верной для t=0.
• Определяем коэффциеинт S равный числ заведомо большему, чем нужно, чтобы защита на него не срабатывала. Испольузем тор и пишем статистику. Наш клиеент каждые 15 минут выкачивает статистику, сранивает её посредсвом отклонения S с тратсед-статистикой и извещает нас о коэффициенте отличия. Все отличя мы пишем (хотя имея все файлы статистики их можно выудить и оттуда). Таким образом, мы работаем со случайной величиной, которая принимает значения S равные отклонению текущего скачанного от трастед.
• Отклонение S определяется как S = (C-1)² + (D-1)², где C и D определяются как сказал unknown, но(!), не между сосденими по времени скачанными статистиками, а между только что скачанной и трастед-статистикой.
• Изучив за месяц коэффициенты, обдумываем то что получили. Берём свою последнюю скачанную за месяц статистику и сраниваем её со статистикой соседей. Если аномальных отклонений нет, переопределяем: трастед = последняя статистика, и у нас начинается следующий месяц.
• По желанию включаем уровень дебаг, который позволит нам сохранять всю статистику что мы выкаичваем с сети тор. Если будут обнаружены аномалии, мы задним числом выясним кто пожписал статистику и что там за ключи.
• Программа настраивается так же как и я описал ранее: работая с коэффициентами, включёнными в конфиге тор-клеинт останавливает работу, если S на какой-то скачке превысило допустимое указанное в конфиге значение.
• Включение красной кнопки "для всех", будет сводиться лишь к раскомменичванию ряда опций из тех что я уже предложил, и выставлению правильных коэффициентов, полученных энтузиастами после "изучения на сырую" статистики тор.
• Целью всего этого является попытка снять катастрофичную привязку к авторитету DA. Если все будут работать с трастед-статистиками и сраниваться друг с другом, DA не сможет сделать вообще ничего, ибо каждый её шаг вперёд будет зависеть от всех предыдущих. Так что, единственный раз, еслди в условный начальный момент времени все юзеры запаслись правильной статистикой и DA им ненаврал, то далее DA вообще не сможет дезынформировать пользователй. – Да, именно поэтмоу я отказался от форсирования включения тор-нод в PGP-сеть доверия, сказав что наша модель достаточна для отражения атаки.
• Впоследствии схему можно доработать с учётом реальностей сети тор, всё вышепредложенное – как самый первый шаг, что предлаагем Роджеру.
• Конфиг который я писал ранее почти полностью годится для, и легко дорабатывается с учётом позже сказанной критики. Его можно было бы включить в мэйл.

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