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

Значит надо поменять протокол, с учётом возможностей TPE

Нет, это сущностное непреодолимое ограничение. Аналогия: считайте, что компы – люди, а протокол – язык общения. Очевидно, что общаясь с человеком нельзя понять всё, что он думает в данный момент на самом деле. А случаи детекторов лжи как раз соответствуют атакам на побочные электромагнитное и прочие излучение (называется TEMPEST). Поскольку у вас физического доступа ко всем рутерам сети нет, про TEMPEST можете забыть :) В общем, эти рассуждения ведут в оффтопик, а потому прошу придерживаться темы.

X-общем числе узлов это вероятность того, что все узлы будут чистенькими.

Да, ступил чё-то я :)

А если держать принудительно всю сеть под постоянным максимальным напряжением (посредством пакетов пустышек), что нивелирует всплески активности?

Это так может быть только у военных. Некогда на этот счёт уже высказывался unknown. Гражданским институтам иметь такую спецсеть непомерно дорого.

Нет, это сущностное непреодолимое ограничение.

Я бы не был столь категоричен. Используя TPM, можно гарантировать, что исполняемая ОС кошерно-халяльно-православна, а ОС, в свою очередь, может аттестовать исполняемый софт, согласовывая эти данные через Сеть. Это весьма активная область исследований, продвигаемая корпоративным сектором (например, удалённый сотрудник допускается в корпоративную сеть только после того, как ОС пройдёт аттестацию на отсутствие зловредного кода).

Только с практическими реализациями такой архитектуры напряг. Начиная с надёжных TPM, собственно.

Задержки в масштабе TCP (т.е. секунды, пара-тройка десятков секунд) не дадут практической выгоды

По моему, при достаточной нагрузке на сеть, они существенно затруднят корреляционные атаки. А если допустить дополнительный бит метаданных для QoS, могут даже улучшить пропускную способность для торопливых. А простую рандомизацию очереди по-моему надо оформить в виде предложения разработчикам. (Сам хотел было Написать патч, да уж больно реализация очередей в Tor'e "нертивиальная")

сущностное непреодолимое ограничение.

А вот как пришлют вам по заказу программу, зашифрованную открытым ключём вашего TPM, которая будет подписывать все исходящие из неё в сеть пакеты... :)
Осталось придумать как убедиться, что вам прислали именно то, что вы хотели и ничего больше. Ну тут может какие-нибудь протоколы с нулевым разглашением сгодятся.

Гражданским институтам иметь такую спецсеть непомерно дорого.

Всё болше людей переходят на безлимит, однако.

По моему

Мне объяснять надоело. Но, раз по-вашему так, напишите работу с обоснованием, представьте её на PET, оформите proposal в or-dev.

Мне объяснять надоело

Вы не объясняете а просто утверждаете. Корреляции ведь в долях секунды меряют, и отклонение даже на такое время затруднит атаку.

Допустим, у нас есть сферический TPM в вакууме, он позволяет запускать только ПО подписанное производителем TPM, и может выдавать этому ПО удостоверяющие подписи, которые затем используются в протоколе. Предположим, что наше ПО запускается без ОС, и не содержит никаких уязвимостей могущих привести к модификации его кода в памяти. Тогда, обладая физическим доступом к системе, мы можем быть уверены в отсутствии модификаций ПО в той степени, в какой мы доверяем производителю TPM.
Если мы не имеем физического доступа, то такой уверенности уже быть не может, поскольку ПО может быть модифицировано в памяти с помощью прямого подключения к железу (достаточно вставить PCI плату, подключить IDE или SATA устройство, или даже просто девайс к порту 1394). Это делается гораздо проще, чем кажется, и некоторые методы даже не требуют спецтехники.
Если рассматривать реальную систему, то наше ПО будет работать под какой-либо ОС, а в любой ОС имеются уязвимости на исполнение кода в ядре, а драйвера железа имеют еще больше таких уязвимостей. Это позволяет локальному пользователю обойти ограничения TPM без применения аппаратных методов.
Ну и наконец, если применить такую модель безопасности именно к Tor, то всё становиться ещё плачевнее. Для создания злонамеренного узла не обязательно модифицировать Tor, достаточно написать собирающую статистику программу. Даже не обязательно писать полноценную программу, можно собирать статистику соединений скриптом запускающим netstat, и инжектировать отпечатки в трафик путем изменения правил фаерволла. Ну и наконец, можно вообще не трогать Tor сервер, а просто подключить его к интернету через злонамеренный маршрутизатор, который будет всё это делать.
Еще добавим проблему доверия к самому TPM. Кто будет решать, какой софт можно юзать, а какой нельзя? Кто гарантирует, что ключом TPM не будет подписан вредоносный код? Наивно считать, что заинтересованные лица не смогут получить нужную им подпись для модифицированного софта.

Сферический TPM в вакууме должен представлять из себя однокристальный (на одной микросхеме вместе с памятью и с защитой от физического взлома) компьютер, которому можно поручить выполнение критических операций, в случае "чесночного" рутинга (в Tor'e – "луковый") это может быть перепаковка пакетов, включение в них хэша исполняемого в TPM кода и подписание их.
Если же ещё и производство подобного TMP сделать открытым и публично проверяемым, то есть надежда, что даже "заинтересованным лицам" не удастся его подделать. В общем, мечтать не вредно.

включение в них хэша исполняемого в TPM кода

, заверенного ключом этого TPM. Это должна быть встроенная команда.

простую рандомизацию очереди

Невозможно рандомизировать очередь, поскольку в Tor оперируют в терминах потоков. Краевой узел не имеет другой информации о порядке передачи данных в место назначения, кроме как в полученном по цепочке. Реализация очередей очень простая, поскольку они в настоящий момент не являются элементом дизайна сети. Очереди служат лишь для разгрузки output буфера, и более аккуратного использования памяти. О рандомизации можно говорить лишь при описании процесса выбора очереди из которой данные пойдут "в провод". Интуитивно кажется, что такая рандомизация может чему-то и поможет, но вдруг это лишь откроет возможности к новым атакам, или в лучшем случае просто бессмысленно? (Заплатки в код это самое простое и последнее что необходимо сделать, в процессе реализации чего-либо.)
PS: Не настаиваю на правильности изложенного. Кроме того иногда (кому и всегда :>) проще выразить всё патчем, просто для того что бы начать думать над предложенным.

Вы не объясняете а просто утверждаете. Корреляции ведь в долях секунды меряют, и отклонение даже на такое время затруднит атаку.

Присоединяюсь, мне тоже не ясно. Атака на кореляцию трафика это когда в начале и конце соединения стоят враги и видят: "пошёл пакет на старте, через 5 секунд пошёл пакет на финише. 3 пакета здесь, 3 пакета там. Снова и снова, через одинаковые промежутки времени. Значит, это одна цепочка". Так? Тогда, кажется, задерки, меньшей либо равной времени пинга должно хватить с избытком. А это вполне приемлемо – в худшем случае сеть замедлится в два раза.

Атака на кореляцию трафика это

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

Реализация очередей очень простая

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

О рандомизации можно говорить лишь при описании процесса выбора очереди из которой данные пойдут "в провод"

Угу, речь об этом. Входной буфер, кстати, тоже есть.

надо писать свою реализацию

По хорошему, надо вообще отказываться от очередей в явном или не явном виде. От них все беды и атаки, и не только в Tor. Очереди должны быть или сильно сокращены или удалены полностью, но это невозможно в нынешнем виде. Релизацию контроля доставки нужно переносить на уровни клиента и/или краевого узла, и это возможно лишь после миграции на UDP транспорт.

Я бы не был столь категоричен. Используя TPM, можно гарантировать, что исполняемая ОС кошерно-халяльно-православна, а ОС, в свою очередь, может аттестовать исполняемый софт, согласовывая эти данные через Сеть

Ну... я имел в виду не это. Здесь вы очень хорошо хватанули. Перевести абсолютно все компьютеры в мире на TPM – это не тривиально. Кроме того, даже пусть это будет и так, вера в невзламываемость логики физических схем сродни вере в невзламываемость ассемблерного кода. С кое-какими элементами того, как это делается можно ознакомиться в "игре в умные карты" от Киви Берда. А раз кто-то сможет утянуть глобальные ключи, значит он сможет построить программный эмулятор TPM. В итоге "защита" с его помощью будет выглядеть как "защита авторских прав с помощью DRM". Проблему можно решить, вводя уг. ответственность за модификацию кода программ, используемых на PC. Скорее это ближе пока к фантастике. Да, и не следует забывать, что на свете много стран. И одна страна не захочет, чтобы ключами к её TPM владела какая-то другая. А если одними и теми же сакральными ключами будут владеть все страны (а это слишком большое число), то кто-то их быстро и сольёт.

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

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

Присоединяюсь, мне тоже не ясно. Атака на кореляцию трафика это когда в начале и конце соединения стоят враги и видят: "пошёл пакет на старте, через 5 секунд пошёл пакет на финише. 3 пакета здесь, 3 пакета там. Снова и снова, через одинаковые промежутки времени. Значит, это одна цепочка". Так?

Мне тоже не ясно. Я думаю, здесь всё чуть сложнее. Измеряется число пакетов, прошедших за какой-то промежуток времени (не обязательно совсем маленький). Раз все пакеты всё равно должны пройти по указанному маршруту, то усреднённая статистика пакетов, прошедших через измеряемые точки, не изменится. А из разности потоков и можно выудить, кто откуда пришёл. Для таких задач, полагаю, есть готовые модели по статистическому анализу. Моё предположение в том, что введение задержек не нивелирует возможность корреляций, а лишь несколько затрудннит их ценой существенного усложнения протокола, его реализации, и его производительности для конечных пользователей. Имхо, именно поэтому от этой полумеры и отказались. Интуитивные рассуждения о "задержках" здесь неприемлемы: нужно брать формальную строгую математику, и вычислять корреляции – это отдельная задача, требующая квалификации. Скорей всего, для конкретно тора её ещё никто не решал, чтобы дать ответ: на что конкретно и в какой степени повлияли бы эти корреляции. Btw, почему матмодели не очень перспективны в плане исследований на данном этапе – потому что много side-эффектов в тор и чисто технических тонкостей, полный учёт которых нетривиален. В частности, делая небольшие нюансы на чисто технической стороне дела, можно смущественно облегчить деанонимизацию. К примеру, ранее писали о том, что tor-трафик можно отличить от стороннего https-трафика из-за того, что горе-разработчики не подумали о точной его маскировке под https. Стороннему же математику разбираться с тонкостями реализации https, tcp/ip и прочего очень муторно, а без этого ажекватное исследование протокола невозможно, равно как и построение его модели. Да, ещё вспомнил, как, кажется, Мухтар, что ли, спрашивал у unknown'а по поводу обнуления какого-то счётчика для https. И вот оказалось что, типа в RFC-то не так, как обычно считают... эффект того же рода.

К примеру, ранее писали о том, что tor-трафик можно отличить от стороннего https-трафика из-за того, что горе-разработчики не подумали о точной его маскировке под https.

Раньше — да. Сейчас уже неактуально.