Простой способ атаки "в обход" tor
Простой способ атаки "в обход" против пользователя Tor.
Протокол сети tor (Onion Routing) имеет топологию статической сети с корневым сертификатом (Root CA). Этот сертификат используется для подписи статистики и ключей независимых серверов, подключаемых к сети Tor. Закрытая часть ключа сертификата принадлежит разработчикам программы tor, открытая зашита в саму программу. Поэтому пользователи всегда доверяют этому сертификату так же как и самой запускаемой ими программе, работу которой они могут протестировать и посмотреть исходники.
Могут ли разработчики злоупотребить наличием своего закрытого ключа? На первый взгляд нет. Серверы в сеть подключаются хотя и под контролем разработчиков, но в целом принадлежат множеству разных людей и организаций. Если разработчики начнут делать с помощью своего закрытого ключа фальшивые подписи на корневом сервере статистики или его зеркалах, то владельцы серверов это заметят, поднимут скандал, отключат сервера и подорвут репутацию проекта.
Однако, если использовать Tor в качестве "приманки" против конкретного пользователя, то всё делается достаточно гладко.
Вот как это может происходить:
1) Представитель силового ведомства Мэллори получает ордер на прослушивание интернет-соединения Алисы, которая использует Tor.
При этом он также получает ордер на выдачу закрытого ключа сети Tor у разработчиков (или получает его другим способом – прослушивание, кража, взлом сервера, подписывающего статистику).
2) Мэллори также получает ордер на установку у интернет-провайдера Алисы специального оборудования для прозрачной трансляции сетевых адресов (Network Adress Translation). В отличии от обычного NAT, который используют админы, это оборудование и соотвествующее программное обеспечение должно максимально незаметно подменять адреса из выбранного списка, имитировать соединение с ними, обрабатывать и отправлять траффик дальше.
3) Если Алиса использует обычное, не связанное с Tor, интернет-соединение, Мэллори просто прослушивает траффик сниффером (эту скучную работу он может поручить Еве).
4) Если Алиса посылает запрос статистики на один из серверов Tor, Мэллори осуществляет простейшую атаку человека посредине "man-in-the-middle". Он создает имитацию соединения с этим IP адресом, а на самом деле отправляет Алисе пакеты, подписанные похищенным сертификатом.
5) После того как Мэллори дал Алисе скачать фальшивую статистику, с фальшивыми же ключами серверов, заверенную сертификатом разработчиков Tor, он перехватывает все обращения к IP-серверам Tor, расшифровывает весь траффик Алисы теми ключами, которые он ей же и подсунул.
6) Для предотвращения подозрений со стороны Алисы Мэллори дополнительно фальсифицирует ответ от всех серверов, которые возвращают IP Алисы (http://serifos.eecs.harvard.edu/cgi-bin/ipaddr.pl?tor=1) и другие.
Правда этот метод не сработает, если Алиса зайдёт на SSL-защищённый сайт, от которого нет ключа у Мэллори и увидит там свой IP, не соответствующий сети tor.
В таком случае Мэллори может перенаправлять конечный траффик Алисы на свои подконтрольные сервера, зарегистрированные в сети Tor.
Имеем классическую (хотя слегка модифицированную) атаку "человека посредине" на сеть с корневым сертификатом.
Это гораздо проще, чем статистический анализ, атаки пересечения или глобального наблюдателя. И результат при соблюдении всего двух условий (достать корневой ключ, получить согласие провайдера, или даже взломать его маршрутизатор без его ведома) не так уж сложно.
Спасибо Spinore http://www.pgpru.com/forum/viewtopic.php?p=11332#11332
который предложил множество интересных идей и вдохновил меня на более внимательное изучение анонимных протоколов, в результате чего мне и пришла в голову мысль насчёт возможности атаки на Tor и использования его в качестве средства индивидуального прослушивания траффика, после чего я и написал этот текст.
Spinore, а Вы хотели ключ хранить в анонимной сети! Современной криптографии пока ещё очень далеко до этого.
Особое внимание при написании данного текста я уделил прекрасному обзору Андреаса Хирта http://pages.cpsc.ucalgary.ca/~hirt
всвязи с его тезисами о том, что в течении давдцати лет так и не было разработано удовлетворительно стойкого и практичного анонимного сетевого протокола, надёжных сведений по доказательству стойкости и классификации атак на такие протоколы в открытой литературе крайне мало, а исследователи то и дело с подозрительным постоянством находят неописанные, хотя и очевидные атаки.
Также, советую тем, кто хочет и дальше копать в этом направлении ознакомиться с архивом проекта Gnunet.
http://www.gnunet.org/papers.php3?xlang=English
О! Предвосхитили :) Зря объяснял.
Ужас! Так, срочно учим математику. У нас есть 2 случайных величины. Для простоты забъём на то, зависимы они или нет. Нам нужен случай, когда обе из них отклоняются не сильно от некоего среднего. Вводим стандартное отклонение и используем МНК.
Поскольку
Поучаем: S(pinore) = (C – 1)^^2 + (D – 1)^^2.
В идеале таким образом определённое S будет стремиться к нулю в случае стабильной сети. И чем оно больше, тем нестабильнее сеть.
Вроде только я пил, у вас-то почему мнения перегреты?
Всё-таки фиксим формулы с учётом того, что должны равняться не на предыдущий шаг а не некую предполагаемую среднюю статистику. Подробнее я описал раньше что это такое и зачем нужно.
И чё, привязываться к изменениям файлов статистики? Как мониторить-та? Или как дибилы-программеры мониторить "не появилось ли что нового" обращаясь к файлу каждые 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.
- Вводим измерение относительно нулевого момента времени (средней (доверяемой) статистики).
Я ушёл спать, смогу ответить ещё что-нибудь уже только вечером.комментариев: 11558 документов: 1036 редакций: 4118
Тогда надо так: x^^2^^.
s/minds/heads/ (или brains), но, на мой взгляд, это не принципиально. И если есть замечания к переводу, критикуйте, пожалуйста, последнюю версию перевода, а не первую.
Файл статистики не меняется ежесекундно. Внешней программе достаточно каждую секунду проверять время последнего изменения файла и запускать алгоритм сравнения, если файл был изменён после последней такой же проверки.
Тогда, наверное, t=tn.
комментариев: 9796 документов: 488 редакций: 5664
Да я понимаю к чему Вы spinore и ygrek клоните, вы хотите получить красивый нормированный и симметричный критерий, который бы укладывался в "правило трёх сигм" (нам бы одной хватило для 90% вероятности) и т.д. Как будто сеть стабильна хотя бы в некотором временном интервале и есть некоторый критерий, по которому пользователи не должны сильно отклоняться.
Во-первых, я не уверен вообще может ли он существовать и будет ли он иметь смысл.
Можно ли будет доказать, что он показывает оптимальным образом все атаки?
Во-вторых, я хотел применить другой подход: пользователи сравнивают показатель для одного и того же времени. Если у них (у всех) был скачок в одно и то же время, то скорее всего никакой атаки нет (или у них всё равно нет шансов её обнаружить путём нахождения различий). Далее могут статусы сравнивать. Кстати, статусы выдаются голосованием в V3 не чаще раз в 15 минут (про исключения не знаю).
Я не говорю, что мой подход лучше (может хуже): мы на разные аспекты упор делаем. Сравнение отклонения от некоего "правильного" значения или сравнение любого отклонения, которого у пользователя не было до этого и больше упор на синхронность его измений между пользователями.
C и D зависимы, если вы хотите их просто так считать по отдельности, то не проблема. C можно считать не только как изменение количества ключей, но и IP-адресов, имён.
Просто реально, есть разные случаи:
Вероятность с частичным отравлением кэша статуса невелика – это слишком рискованно для противника. Пользователь может соединиться с реальным узлом и снова скачать нормальную статистику, если при этом он будет мониторить ситуацию, то он зафиксирует ещё более подозрительные колебания параметров. Для этого противник оставлять в статусе часть реальных узлов, но блокировать соединения с ними, что из файла статистики вообще не отследить. Это хорошо бы выводить из самой программы и тоже учитывать как некий коэффициент.
комментариев: 9796 документов: 488 редакций: 5664
Неправильно выразился. Планировалось получить скачок между шагами, который был бы одинаков у пользователей в тот же промежуток времени.
комментариев: 98 документов: 8 редакций: 10
unknown, наверное вы правы, красивый идеальный критерий скорее всего работать не будет, т.к. мы имеем дело с неидеальным грубым реальным миром :) – но ведь интересно..
Хочется в общем посмотреть статистику сети, не обязательно с точки зрения этой атаки.
комментариев: 9796 документов: 488 редакций: 5664
Мне тоже интересно, а статистику можно изучать, никто не мешает.
Можно наизобретать массу разных моделей и все визуализировать. Вполне возможно, что совершенно разные способы построения критериев будут работать (или не будут вообще). Вот у нас уже почти три есть. Можно было бы все три чисто навскидку сравнить.
Возможно моя идея с одним критерием действительно неосуществима и порочна изначально.
Просто заставить даже очень интересующихся пользователей смотреть больше чем на один график и сравнивать более одного параметра малореально.
Я не ставлю чёткий таймлайн (с идеальными критериями можно полгода провозиться), но хочется отправить то что есть (и так уже много).
Если что-то получится ещё, будет повод о себе напомнить и следующее письмо отправить.
Я даже не знаю что есть критерий трёх сигм, но предполагаю что речь идёт о неравенстве Чебышева и вероятность отклонений больших трёх сигм. Собственное, речь не об этом. Мы можем всего лишь заменив одни формулы на другие существенно улучшить качество оценки – так почему бы это не сделать?!
Для начала, нужно получить список всех атак. Потом уже ставить подобный вопрос. Пока что я увидел только одно существенное нарекание в треде: куча нод систематически включается только на определённое время суток и т.д. Касаемое конеретно этого обстоятельства нужно просто оценить: куча – это сколько процентов? 50? 5? Если на фоне общего числа нод это не великое колебание, то проблем нет, всё решается лишь выставлением ограничителя на S, который бы допускал такие суточные изменения, но не пропускал бы атаки.
Вот... Только теперь-то я вас понял, могу уже конструктивно повозражать по поводу подходов :) Вы, unknown, смотрите на мониторинг этой атаки как на обычное исследование скорее, а не как на нечто, что тут же должно давать конкретный технический продукт защиты. Я же смотрю на неё скорее как практик которому нужна защита от неё и как можно скорее. В нейтральном анализе смысле различия между подходами вот каковы:
Вы включаете "дебаг-уровень отладки" статистики и пишете пошаговые сравнения. Вы надеетесь, что задним числом сравнив свою статистику (куча фйлов, так как они обновляются относительно часто) в соответствующие времена со статистикой соседа выясните правду. Во-первых, минусы:
- Реакция исключительно постфактум, но никогда не до.
- Слишком много файлов и объёмов данных, которые прийдётся сравнивать.
- Будет сложно найти кучу народа, кто согласился бы писать все скачки статистики втечение длительного промежутка времени, всего лишь ради одной-единственной атаки (а атак на тор кучу можно придумать).
- Поптыка синхронизовывать статистику с сстатистикой соседа влекёт за собой трудности (чё, будем каждые 15 минут друг с другом файлами статистики перекидываться?).
Вы уж меня извините, это может быть всполедствии включено как дополнительная мера "дебаг-уровня", но с практической точки зрения она пока мало чего не даёт. Мы должны думать во-первых о других и технической стороне дела, в идеале должна быть одна конопка которая будет загараться на атаку и справшивать у пользователя "что едлать? Идти или не идти дальше?" либо будет действовать в рамках заданных для неё ограничений. "Любите юзера", что называется :) Он должен выставить 2-3 разумных числа-переметра в конфиге и забыть про эту атаку – ему нужно пользоваться тор-сетью а не изучать статистики(!).Теперь смотрим то что я предлагаю:
- Сравниаем друг с другом только среднюю статистику. Её можно сравнивать иногда, например раз в месяц (не думаю что за месяц сильно меняется число узлов в сети тор). При попытке мониторить атаку заранее нам уже не нужно каждые 15 минут обмениваться файлами статистики – достаточно раз в месяц этого сделать. А это уже куда легче технически.
- Когда происходит атака, я её могу засчеь в реальном времени и остановить программу, я её обнаруживаю до, а не после.
- Предложенная схема не сложнее вашей, но она уже технически дорабатываема до уровня конкретной реализации и будет реально давтаь разумную защиту при небольшом геморрое.
Поэтому я предлагаю начать с простого: сделаем сравнение с "трастед-средним", а уже потом будем смотреть на динамику (это что вы предлагаете).Самый концептуальный момент – в том, что равняясь на среднее всегда самому уединённо видно, есть лиатака и что происходит с сетью, а равняясь на предыдущий шаг, видно лишь малое отклонение, из которого ничего толком заключить нельзя (ибо надо смотреть уже на совокупную динамику за массу предыдущих шагов по уму, я по сути предложил лишь упрощённый вариант – сравниваемся с начальным моментм времени). Вы поймите, что атака не обязательно есть марковский процесс (на шаге k всё ништяк а на шаге k+1 противник ввёл все свои фиктивные нод или что-то подобное), проивник может сделать её немарковской, и предполагая что вы включили защиту от неё заранее, постепенно впрыскивать ноды пока не доведёт вашу итоговую статистику до до уровня нужной для атаки (а поскольку в реальном времени вам не удобвно сравниться с сосдеями каждые 15 минут, вы вообще ничего не заметите. Я уж не говорю о том, насколько легко/трудно противнику будет понять, с кем вы сравниваете статистику а с кем нет, а то он может прдделывать её для группы связянных друг с другом пользователей).
Давайте ближе к Земле и практике:
Какая из этих атак не отлавливается посредством измерения S = (C – 1)2 + (D-1)2?
Грамотное замечание, но всё начинается с деления общей задачи на часть независимых модулей. По моему мнению, указанное вами дополнение относится к дополнительной усложнённой атаке, и его слеждует рассматривать как второй шаге приближения к идеалу, а пока мы рассматриваем 1ый, и нам нужно 1ый шаг что можно сделать втолковать Роджеру.
Чего бояться, дорабатываем до нормально состояния письмо с учётом поправок и отправляем. Предложив хотя бы что-то мы упрощаем задачу разработчикам тор. В добавке укажем: "Это наше предложение, может быть вы увидите ошибки в его конструкции и придумаете что-то своё, лучшее".
Можно строго показать что почти для любой куйни достаточно одного числа для оценки и оно называется МНК. Самих величин может быть хоть миллиён (просто надо будет в общем случае понять как сконструировать правильные случайные величирны из того что наблюдаем а потом применить уже к ним МНК).
комментариев: 9 документов: 0 редакций: 1
Тот метод, который предлагается, называется средним по скользящему окну (sliding window average).
Идея в том, что усредняются характеристики за время от T-dT до T, где dT-ширина окна. Такие методы применяются
также в техническом анализе (статистика рынков валют и акций). Метод работает потому, что в большом количестве случаев
системы эргодичны (т.е. среднее "по ансамблю" совпадает со "средним по времени").
Кроме того, spinore предлагает брать средние на нескольких временных масштабах (разных dT). Это связано с тем,
что система узлов сети Tor имеет несколько характерных времен (суточные колебания, и т.п.). Поэтому это тоже здравая идея.
Естественно константы (ширины окон, пороговые значения отклонений средних) надо выбирать аккуратно. Здесь место и для
теоретических исследований, и для экспериментов. Есть где unknown-у развернуться :)
Да, я думаю, что можно считать не только средние, но и дисперсии. Аномальные значения тоже могут свидетельствовать об
атаке.
комментариев: 9796 документов: 488 редакций: 5664
spinore, Вы уже пытаетесь мне втолковать тоже, что и Роджер, я это понимаю прекрасно. Я согласен, это идеально было бы.
Но он высказал и свои сомнения по поводу этого: слишком чувствительные настройки – много ложных срабатываний, слишком грубые – можно пропустить атаку.
Я предлагаю паралелльную идею – временно отказаться от построения реальной защиты и заменить её на коллективный аудит, основанный на сообществах заинтересованныхх пользователей. В расчёте, что дурить многих пользователей одновременно противник не сможет и не сможет предсказать каким окольным путём пользователь попытается прорвать изоляцию и узнать правду о сети (кстати это obscurity и слишком большое перекладывание отвественности на пользователя, что согласен плохо: пользователь вынужден думать и действовать также изворотливо, как и атакующий, а это потенциально проигрышная позиция).
Тут важно то, что можно выявить "левые" ключи и после сравнения статусов от всех добровольцев за один период времени выявить у кого есть "левые" статусы и предъявить этот "обвинительный" документ как доказательство нечестности DA. Что-то вроде наблюдателя на выборах.
Ещё одно рабочее упрощение: атака проводится только за один шаг (максимум несколько). В расчёте, что "delayed partial cache poisoning" почти невозможен, если пользователь может на следующем шаге снова скачать правильный статус с правильного зеркала.
Ну допустим, две тысячи узлов. Противник вбросил или заменил 200 виртуальных фальшивых и "разместил" на них "более свежие статусы", в расчёте, что пользователь их скачает и в каждом новом статусе он будет заменять по только по двести узлов, а не все сразу.
Теоретически он может тогда вообще гладко обойти вообще любую статистическую диагностику, укладываясь в погрешность естественных колебаний.
Но: существет вероятность, что пользователь скачает правильный статус из оставшихся узлов (он ведь их сам выбирает случайно, если их не блокируют) и получит как раз большой скачок при откате статистики назад к правильному значению.
Вот здесь у меня есть одно скептическое соображение, которое могут подтвердить только разработчики ну или мы сами путём долгих наблюдений. Понятно, что есть динамика, но я не верю, что trusted-среднее за любой разумный промежуток времени реально есть.
2 Vadim_Z, я об этом тоже подумал. Только в этом реально можно увязнуть.
Сеть tor статистически ближе к поведению толпы людей, а то что мы можем померить – это как биржевой курс. Мы посчитаем среднее, а он возьмёт и скакать начнёт, или обвалится, или офигенно стабилизируется в зависимости от чьих-то настроений или обстановки в мире. Завтра в Германии или где-то примут новый закон, все операторы перепугаются и куча нод отрубится. После завтра закон понаставят кучу новых нод с новой альфа-версий. После-после завтра в этой версии найдут баг, узлы отключаться, наши средние критерии опять уедут.
Да мне Ваш S чисто внешне больше нравится, я понимаю, что он формально более правильный, универсальный и в него при необходимости можно понапихать сколь угодно много параметров.
Не учесть таким универсальным способом, что когда C и D сильно скачут это плохо, но ещё хуже когда есть определённые корреляции между ними в этих скачках. Причём некоторые корреляции – "хорошие" или "смягчающие" друг друга (немного увеличилось число узлов, но и количество изменившихся ключей возросло на столько же, а если C и D одновременно в сторону уменьшения, то это ещё лучше, а снижение ниже некоторого предела – опять плохо, это вообще отдельный параметр должен быть), а некоторые корреляции "плохие" (если C и D ползут в разные стороны, то это хуже; уменьшение D – это в принципе хуже, чем увеличение C и т.д.).
Т.е. при разных соотношениях C и D мы имеем разные состояния системы. Причём смену IP адресов тоже надо учитывать (не знаю как).
Если вам ближе физические аналогии (тут меня можете смело поправить если слишком наивно): Вы пытаетесь просто рассмотреть все параметры, как независимые, не имеющие взаимосвязи или конкретного смысла.
Я же попытался представить некую модель системы, на которую действуют разные факторы, ну как например температура и давление. Как если бы мы ожидали, что при опредлённом давлении будет опредлённая температура внутри какой-то установки или реактора, которые мы полностью не контролируем (не зная точного закона изменения, а только на основании предшествующих на один-два шага данных), а если получается слишком большое и резкое расхождение c ожидаемым, значит система стала нестабильной.
Только, это также неблагодарно как считать прогноз экономический, политический, поведенческий когда все факторы работают только приблизительно.
Уже обсуждали много раз. Опция для параноиков, и после исследований средних и дисперсий возможно включим уже для всех. Для начала она в любом случае будет как для параноиков, какая бы она не была.
А нафига?? Если то что я предлагаю не сложнее, но зато сразу заземляется? А куда ваш аудит пришить? Кто этим будет заниматься? Ну и по сути, "случайная величина"... её ни к чему не пришить, и она легко обходится.
Так не вопрос – добавляем ещё одну дебаг-опцию в конфиг и пишем: сохранять все скачанный статусы, с пометкой их времени. Потом заним числом можно понять, какие ключи что и у кого.
А что, delayed partial cache poisoning это что-то слишком экстраординароное? И покажите мне почему мой подход её не отловит, а то я это в упор не вижу. Повторяю – среднее апгрейдится время от времени мануально. Ща по пгп обращусь к тому кого знаю лично, попрошу запустить тор и скачать, или ещё чё-нить подобное сделаю. И буду изучать, действительно ли статистика за это время поменялась так как как мне предъявляет сервер.
Если кого ввёл в заблуждение, "средняя статистика" – это не усреднение в обычном смысле по статистикам. Это просто одна какая-то статистика, которую мы проверили по разным каналам и стали ей доверять. Правильнее было бы её называть доверяемой статистикой. Но посольку если бы мы знали истиное среднее в отсутствие ататки, можно было бы сравнивать с ним (но мы его не знаем и знать не будем), вот потому по аналогии я и гвоорю что "среднее". В письме лучше напистаь trasted конечно, чтобы не вводить никого в заблуждение.
Меня ещё поправили что S в моём опредлении не есть дисперися, а всего-навсего "отклонение" от trusted-статистики, которая по опр. полагается верной для t=0.
Ну и почему мой метод не сработает? Изучим статистику и поймём праивльные коэффициенты которые в норме никогда не превышаются.
Нет, не обойдёт :) Пример в студию. Коэффициенты подбираются так, чтобы суточные колебания пропустить а атаку – нет.
См. определение выше. Я очень аккуратно описал что я понимаю под этим термином в том посте где писал конфиг для, опираясь на моё понимание того ка как работает тор. Жалко, что никто внимательно тот пост вы не прочитали. Она не имеет прямого отношения с реальным средним по релаьной сети(!), потому что мы не можем гарантировать что "ататки не было".
И что? Я не думаю что сеть тор до такой степени нестабильна. Или под предлогом того что всё можно обойти, вообще опустим лапы и перестанем бороться?
Мы измеряем не корреляции, в вероятность атаки. Уклонение от trusted всё это прекрасно ловит.
Они физически разные, но с точки зрения вероятности атаки несут угрозу с одинаковой вероятностью.
ЦПТ и ЗБЧ ещё никто не отменял ©
2 SATtva: мы должны прийти к единому выводу, тогда и приверим ещё раз ваше письмо на предмет как соответствия "физике", так и "языку". Пока я хочу успокоить unknown'а :) То ли я запутал всех своими терминами (сорри если что), то ли кто-то упорно тупит, не могу понять.
Ладно, я попытаюсь кратко просуммировать то что предлагал и попытаюсь использовать адекватные термины, чтоб без заблуждений:
Я уже очень устал переливать из пустого в порожнее, так что критику просьба пистаь конструктиную: конкретная атака, которую предложенная выше схема не ловит, и она не оговорина в спике того, что пока я осталяю за кадром.