Перевод MoneroKon 2019: Луковицы Dandelion - защита анонимности транзакций в Monero

Тема в разделе "Журналы о Monero", создана пользователем Mr. Pickles, 3 сен 2019.

  1. Mr. Pickles

    Команда форума Модератор Редактор

    Регистрация:
    11 сен 2017
    Сообщения:
    793
    Симпатии:
    229
    1.jpg

    Ли Кладжет является программистом, работающим, в первую очередь, в области компьютерных сетей / безопасности, а также является оплачиваемым контрибьютором кода проекта Monero, начиная с 2016 года. Наибольшую активность проявил при внесении изменений в алгоритм доказательства работы (PoW), при разработке сервера «лёгкого» кошелька, который будет реализован вскоре, а также в повышении анонимности трансляции транзакций Monero.

    Аннотация

    Протокол Dandelion и Tor / «луковая» маршрутизация являются наиболее распространёнными технологиями маскировки IP источника криптовалютных транзакций. Обе эти технологии имеют свои ограничения, которые никуда не денутся, если не реализовать дополнительные средства защиты. Протокол Dandelion обеспечивает защиту от атак Сивиллы, но не от пассивного мониторинга ISP. Tor защищает от атак Сивиллы и пассивного мониторинга ISP на базовом уровне, но повышает угрозу атак Эклипс, а также восприимчив к статистическому мониторингу пропускной способности. Проект Monero должен попытаться найти способ ослабить все эти угрозы путём использования Tor / луковой маршрутизации на этапе обнаружения локальных узлов и на фазе «выбеленного» стебля (Dandelion++) при трансляции транзакций. В ходе выступления будут рассмотрены эти угрозы и способы их нейтрализации, а также текущее состояние их реализации в Monero.

    Стенограмма:

    Итак, начнём.

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

    Продолжаем.

    Итак, верхняя часть по большей части относится к тому, что было реализовано к данному моменту, но в отношении анонимности блокчейна. Нижняя часть — то, о чём мы поговорим в рамках этого выступления, то есть о защите анонимности IP источников транзакций. То, что выделено красным, относится непосредственно к теме выступления. Оппортунистическое шифрование — это то, к чему в конечном итоге придёт Monero, но оно потребует какого-то времени для проведения исследований.

    И так как речь идёт о Monero, мы не просто реализуем I2P и Tor, мы также добавляем белый шум, возможно, что-то вроде Dandelion. Речь идёт не о Dandelion++, я должен отметить это, но это будут какие-то дополнительные средства защиты для вещей, о которых только что говорил Джош, когда кто-то видит сразу множество точек во всём интернете, в общем, мы ещё доберёмся до этого по ходу выступления.

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

    Документ Dandelion, пожалуй, является наилучшим источником информации о том, как работает этот тип атаки, но, по сути, вы просто создаёте множество сетевых соединений и пытаетесь изучить топологию сети посредством протокола администрирования P2P. Протокол подразумевает некоторый механизм регистрации того, как вы распространяете информацию между своими узлами об узлах, которые вы видели, и происходит утечка именно этого типа информации. Также происходит утечка большого количества информации о транзакциях или их трансляции, поскольку вы можете увидеть, как эта информация перемещается по сети, если вы создали множество сетевых соединений. И всё это основано на статистике, поэтому совсем не факт, что будет работать, опять же, подробности содержатся в документе Dandelion. И чтобы избежать этого, было предложено реализовать протокол Dandelion++, который бы обеспечил защиту от подобного вида слежки. I2P и Tor также могли бы решить эту проблему, но совершенно другим образом.

    Хорошо, теперь о слежке со стороны ISP. Мне кажется, первым пунктом, о котором известно большинству людей (а если и не известно, то они догадываются об этом), является то, что ISP имеет возможность своего рода глубокого анализа пакетов, то есть, по сути, обработки ваших P2P соединений Monero, и в результате такой провайдер может сказать: «Так, этот человек никогда не получал этой транзакции, но передавал её». Это создаёт некоторую утечку информации, источником которой можете являться именно вы. Таким образом, очевидным способом защиты в данном случае является шифрование. Здесь сложность состоит в том, что нам приходится шифровать нечто вполне определённого размера, что тут же становится публично известным. Таким образом, эти две особенности как бы работают друг против друга. И даже хуже, поэтому moneromooo, один из наших контрибьюторов, реализовал дополнительное заполнение, чтобы избежать этого, то есть происходит заполнение до размера, соответствующего следующей границе, и это, как мы надеемся, позволяет избежать подобной утечки. Проблема состоит в том, что на пике Monero транзакции совершались каждые 5,6 секунды. Таким образом, существовала сильная корреляция между размером... ох, знаете, я не знаю, зачем я рассказываю всё это вам, если могу показать. Итак.

    Это скриншот Wireshark, это основная сеть, не будем размениваться на тестовую. Это единственное соединение в основной сети, и чёрными полосами показана общая пропускная способность, а красными — исходящая пропускная способность. Можно заметить, что существует множество неактивных периодов и коротких всплесков. Таким образом, обладая нереальными навыками работы с Gimp, я даже не смог нарисовать стрелок, чтобы показать это, честно [смех]. Как вы можете видеть, через три деления слева происходит трансляция двух блоков, которые выглядят очень похоже, а загрузки транзакций не происходит, поскольку это так называемые «худые» блоки или fluffy-блоки, мы их так называем, по-моему. Таким образом, передаётся совсем мало информации, но, опять же, выглядит это, ну... кажется, я не объяснил эту часть, это фактически посекундное разбиение, объём пропускной способности, поэтому если вы сожмёте разбиение, а вы можете сделать это там, справа, то всё будет очень похоже, за тем лишь исключением, что конкретно на этот узел затем мной была загружена некоторая информация.

    А теперь, просто чтобы показать вам увеличенную часть... ах да, я не сказал, что в этой части я также отправил транзакцию в течение этого временного интервала. Я отправил реальные деньги просто для этого выступления. Итак, в этой транзакции я отправил примерно 2,5 килобита, и на графике вы видите, скачок именно той суммы, которая передаётся по каналу. Также вы можете наблюдать другие периоды активности, которые, возможно, не могут быть моей транзакцией из-за различного уровня скачка.

    Я не думаю, что вам заметно, это несколько трудно разглядеть, но одна из интересных вещей, связанных с этим соединением, заключается в том, что у меня было на тот момент тридцать четыре соединения, и я, по сути, получил собственную транзакцию от этого человека перед тем, как отправил её, и это интересно. На графике видно, что происходит что-то интересное. Протокол Monero, очевидно, несколько хаотичен, и он использует слишком большой объём пропускной способности, что, как мне кажется, объясняется просто. Итак, это тот же самый временной период, но все мои соединения входящие, я был небрежен, поэтому у меня не было ни одного исходящего. У меня было около двадцати четырёх входящих соединений.

    И я показываю это, чтобы создать у вас представление, что было бы, если бы вы использовали I2P или Tor, ваш ISP увидел бы те же самые взлёты и падения. То есть я хочу сказать, что вы можете практически сразу сказать, я бы мог сказать вам, когда я выдаю команду на запрос каждого узла: «Эй, какие узлы вы видите?», в ответ последует «Я вижу большой всплеск, который повторяется с регулярными интервалами», и вы сможете увидеть это даже через Tor, вы отметите это практически немедленно. И сейчас я хотел бы сказать, что Tor производит то же самое заполнение ячеек, это и выглядит несколько иначе, но заполнение минимально. И снова это те же точки на графике. Через Tor их будет увидеть сложнее, поскольку, и мне кажется, я не объяснял это, а просто предположил. Отличие от Tor состоит в том, что все ваши соединения проходят через ограниченное количество TCP соединений, поэтому графики отличаются, в этом случае будет больше шума, скажем так, который ISP придётся фильтровать.

    Хорошо, итак, учитывая, что ISP следит за вами, шифрование данных через каналы P2P [неразборчиво] или I2P и Tor, я бы сказал, что это лишь частичное решение, поскольку вы некоторым образом полагаетесь на удачу. Если вы и можете скрыть что-то, то только потому, что протокол отправляет что-то в определённый временной период, в течение которого ваши действия маскируются. Именно поэтому моим изначальным предложением на форуме было добавление белого шума посредством использования I2P.

    А теперь мы поговорим на нашу любимую тему, обозначенную Джошем как наличие глобального пассивного злоумышленника. Проблема в случае с таким злоумышленником состоит в том, что в целом они могут реализовать слежку, которая будет, по сути, улучшенной версией того, что было описано выше. Если они смогут наблюдать множество точек сети, они не станут нарушать её топологии, а просто будут следить за ней. От этого сложно защититься. Таким образом, чтобы привести пример, того, что теоретически они могут сделать даже при наличии белого шума, мы можем рассмотреть первый метод, когда будет использоваться множество соединений через Tor, после чего будет сделана попытка деанонимизировать пользователей Tor. И я не хочу сказать, что это будет просто, но, согласно всей академической литературе, это теоретически возможно.

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

    Итак, что такое Dandelion++? Надеюсь, у меня получится вкратце объяснить это. Идея состоит в том, чтобы, ну, фактически здесь преследуются две цели, в частности, изложенные в документе Dandelion++. Это попытка, я покажу вам всё, что они пытаются сделать, на самом деле, постараюсь дать побольше информации. Итак, это попытка предотвращения утечки метаданных, связанных с сетевой информацией. Опять же, это попытка защититься от первого типа слежки, при котором создаётся множество соединений. Таким образом, каждая транзакция на первом этапе, то есть в фазе «стебля», отправляется только по одному соединению. Идея состоит в том, что это снижает шансы на то, что кто-либо из этих шпионов сможет узнать, как транзакция проходит по сети, поскольку снижается вероятность, что они перехватят транзакцию на первом анонимном этапе. Во-вторых, в первой фазе ими выбираются исходящие соединения, что ограничивает возможность нацелиться на человека, так как они создают множество входящих к вам соединений, чтобы заполнить вашу таблицу соединений и вести наблюдение. Таким образом, вам приходится отправлять транзакцию через них. А затем, после того как всё будет отправлено, напоминаю, что это происходит в существующей P2P сети, после нескольких скачков с выбором только исходящих узлов, в конечном счёте в некоторой точке транзакция разойдётся по сети обычным образом. Когда я говорю о «нормальном», я имею в виду, что Monero может улучшить в том числе и то, что происходит в этом случае.

    И мне хотелось бы отметить ещё одну вещь, о чём я сначала не подумал, и это последний пункт, который, возможно, является одним из самых важных. Dandelion++ фактически делает это проще для ISP и других злоумышленников. Сначала это не было очевидным, но одной из вещей, которую видит ISP, является направление соединения. Таким образом, если они следуют протоколу Dandelion, им сразу становится известно, что транзакции идут в одном направлении, таким образом, эвристический подход к фильтрации шума становится даже лучше. И что касается хаотичности: ситуация, когда я получаю собственную транзакцию до того, как отправлю её, никогда не случится. Фактически это делает некоторые виды анализа, используемые другими злоумышленниками, проще. Но в силу самых разных причин Monero, возможно, по-прежнему будет лучше, но более состоятельной в плане реализации, поскольку такой тип слежки является, вероятно, наиболее распространённым, но...

    Теперь, что касается I2P и Tor, мне кажется, Джош уже говорил об этом. Основная идея I2P и Tor состоит в том, чтобы разбить связь между двумя конечными точками, чтобы нельзя было определить, кто это. Вот почему Monero всегда имела это в своих планах, так как если они будут использовать I2P, идея будет состоять в том, что будет совершенно неизвестно, кто принял транзакцию. Таким образом, нам удаётся полностью защититься от первого типа наблюдения, поскольку злоумышленникам не будет известен даже IP отправителя, другого человека на другом конце. Более продвинутые люди, в частности, пассивные злоумышленники, всё-таки смогут извлечь некоторую информацию.

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

    В случае с Monero я надеюсь, в конечном счёте это было учтено.

    То, о чём я рассказываю, фактически будет, скажем, именно этим мы и занимаемся в проекте Monero. Итак, первым предложением, я думаю, вероятно, будет конечная реализация, сделанная moneromoo, мной и ещё несколькими разработчиками протокола Dandelion++ поверх IPv4 и 6. Для ряда пользователей, которые не хотят даже слышать об I2P, это станет опцией, которая по крайней мере позволит избежать некоторых базовых видов слежения, с которыми мы сталкивались в сети Bitcoin и этих других сетях.

    Теперь для тех, кто хочет узнать чуть больше, эти пункты имеют, пожалуй, больше общего с руководством. Я не думаю, что это будет окончательным решением. Сама идея, и я не хочу называть это Dandelion++, так как берутся некоторые их технологии и делаются жёстче, идея состоит в усилении правдоподобного отрицания с точки зрения источника транзакции. Что есть у меня на данный момент, по крайней мере, в моём рабочем варианте кодовой базы, 3 килобайта шума каждые 10-15 секунд, но только при выборе, у меня это включено, но только при выборе двух отправителей. Таким образом, транзакции будут исходить от двух отправителей, как в случае с Dandelion++, и в конечном счёте получатель через I2P или Tor переведёт их в сеть IPv4 или IPv6. Хитрость в том, что, я называю это зонами, потому что они должны быть полностью изолированы, чтобы из этих зон гарантировано не могли утечь никакие метаданные, это первый пункт, отдельные пулы памяти, если мы смешиваем пулы памяти, кто-то, кто будет прощупывать ваш узел на предмет чего-либо, скажет: «Оу, ты видел эту транзакцию раньше. Откуда ты узнал о ней? Я никогда не видел её раньше», - как-то так. Это хорошо иллюстрирует то, о чём уже говорил.

    Одна из интересных вещей, собственно, причина, по которой я заговорил о Dandelion++, состоит в том, что (вообще-то есть множество причин), состоит в том, что моё изначальное предложение состояло в том, чтобы отправлять белый шум на каждый узел. У этого предложения была своя отрицательная обратная сторона, связанная с большим объёмом использования пропускной способности. Или же можно было увеличить интервал задержки, но тогда транзакции проходили бы дольше. Таким образом, используя что-то вроде протокола Dandelion, вы используете меньше соединений для передачи белого шума. Другое преимущество состоит в том, что в этом режиме любой, являющийся глобальным пассивным злоумышленником, по сути, будет вынужден применять первый тип слежения, создавать тысячи соединений через Tor в надежде деанонимизировать пользователей. А затем глобальному злоумышленнику пришлось бы выяснять, прошла транзакция через Tor или нет, и сопоставлять её с конечной точкой, и только затем деанонимизировать конечную точку.

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

    А теперь проговорим об обратных сторонах, которых, на самом деле, немало. Первая состоит в том, что обеспечение максимальной анонимности путём создания выходящего узла Tor или реализации подобной концепции I2P в настоящее время происходит вручную, и это нас не устраивает. Такие процессы всегда должны быть автоматизированы, и это потребует большой работы. Также есть обратная сторона, связанная с использованием пропускной способности. Во многом в этом состоит причина, почему Tor не использует белый шум. И в этом состоит отличие. Они по какой-то причине пытаются защитить трафик Facebook и YouTube, но объём белого шума, необходимого для защиты такого трафика, должен быть абсурдно большим, я даже не знаю насколько, я никогда не занимался его вычислением. Другая обратная сторона — эффект замедления, который касается не только проведения транзакций, если вы пытаетесь проводить свои транзакции за определённый временной период, при использовании этой техники это становится, к сожалению, невозможным, а также это снижает пропускную способность, так как вам приходится ожидать своей очереди, и это создаёт эквивалентный эффект, когда вы можете отправлять транзакции только по 3,93 килобитному соединению. Это я смоделировал здесь довольно неудачно.

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

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

    И ещё одна обратная сторона, которая заключается в упрощении создания большего количества возможностей для проведения атаки Сивиллы, если вас беспокоит blackhole маршрутизация, которая обсуждалась с момента появления первого документа Dandelion, то она могла бы только ухудшить ситуацию, так как становится проще создать альтернативу через Tor или I2P, вам не нужен новый IP-адрес, нужно просто создать новый публичный ключ.

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

    Итак, нами была добавлена поддержка SOCKS, которая, пожалуй, не многие вообще знают, что это такое, отличается от кошелька или демон-программы, которые различают «луковые» и I2P адреса, и это касается только вышедшей версии. Таким образом, если вы настраиваете выходящий узел Tor, вы должны сообщить о нём вашей демон-программе, и ваш кошелёк сможет подсоединиться к нему напрямую через Tor. Он подсоединяется к демону Tor и направляет весь трафик через Tor. Вы также можете, если у вас есть кто-то, кто позволит вам направлять ваши транзакции через Tor и предоставить вам скрытую службу, то вы можете сделать уже сейчас, но учтите, что тут не будет никакой автоматизации.

    Работа над белым шумом продолжается. У меня здесь где-то был ноутбук, на котором есть куча информации по этому вопросу. На самом деле, уже сделано многое. И одним из преимуществ, а я решил ещё и произвести некоторую оптимизацию, одним из преимуществ является то, что здесь будет частично реализован протокол Dandelion++. Под словом «частично» я подразумеваю, что необходимые биты были включены, и необходимость в рефакторинге только что написанного мною кода отсутствует. И мне кажется, что это предложение, то, что мною было реализовано через Tor и I2P, со временем изменится, поскольку есть ряд деталей, требующих доработки. Но мне кажется, это будет гораздо лучше, чем то, что в настоящее время используется Monero, а не используется практически ничего, вот так вот [смех]. И, я думаю, на этом достаточно.

    Вопрос из зала: У меня короткий вопрос, касающийся пулов памяти и идеи зон. Не считаете ли вы, что это может стать источником проблем, связанных с цензурированием транзакций, если определённые майнеры будут использовать узлы в клирнете и с I2P и Tor, и из-за этого можно будет видеть транзакции, проходящие между определёнными зонами, и выбирать только те, что проводятся в клирнете или через I2P и Tor и так далее?

    Этот вопрос относится к blackhole маршрутизации, и в документе Dandelion эта проблема также рассматривается. В этом документе также предлагается использовать раздельные пулы памяти, и это сделано в исходном варианте реализации, и это представляет проблему, поскольку если вы передаёте транзакцию только одному узлу в несколько скачков перед тем, как передать её всем, любой из узлов может попросту вас заблокировать. Поэтому существует процесс, и я не обсуждал эту часть ни с кем из тех, кто работал над протоколом Dandelion++, существует «таймер запрета». То есть каждый «честный» узел устанавливает таймер, и если он видит, что транзакция не возвращается, предполагается, что он отклонит её. Насколько мне известно, это работает именно так, и я вообще не стал реализовывать эту часть, но всё происходит именно так. Это обсуждалось в основном, пожалуй, в оригинальном документе, но, вероятно, и во втором тоже.

    Вопрос из зала: Вы показали график трафика во время подсоединения к Tor?

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

    Вопрос из зала: Вы проводили какой-нибудь сравнительный анализ различных паттернов сообщений I2P и Tor?

    Нет, не проводил. Вы имеете в виду анализ на предмет того, какой из них лучше?

    Да.

    Нет, это было бы интересно, и это необходимо сделать, так как я чувствую, что гораздо меньше людей склоняются к I2P, обычно даже выступают против. Но это было бы интересно, поскольку мы имеем дело с совершенно иным, и мне кажется, что речь сейчас об этом, с совершенно иным решением с точки зрения маршрутизации сообщений в сети. Используется асимметричный паттерн. В случае с Tor сообщения принимаются и отправляются по одним и тем же каналам, а в случае с I2P — по разным. Поэтому мне всегда казалось, что здесь анализ будет более сложным. Но если всё детально не продумать, а мне пришлось бы всё тщательно продумать, если бы я писал программу для деанонимизации, как бы всё выглядело? Так что нет, я не проводил анализа, к сожалению. И я не знаю никого, кто сделал бы это, но если кто-то знает...

    Вопрос из зала: Я слышал такую историю, что сеть Tor значительно больше, чем сеть I2P, начиная с того, что она популярнее...

    О да, это тоже интересный момент. Да.

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

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

    Правда? Хорошо. Подождите секундочку, пожалуй, вернёмся к вопросу, возьмите микрофон.

    Да, я сказал, что количество составляет примерно пятьдесят тысяч в сети I2P и около семи тысяч в сети Tor, но основная разница состоит в том, что каждый пользователь I2P также является маршрутизатором, и это значительное отличие, а маршрутизаторы Tor являются волонтёрами, создающими узлы именно для реализации этой цели.

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

    Верно.

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

    Вопрос из зала: Мне на ум пришёл один вопрос: что произойдёт, если создать полный узел Monero, но не использовать его для проведения собственных транзакций? А затем вместо этого подсоединиться к другому узлу, чтобы отправлять собственные транзакции, чтобы, например, таким образом защититься от слежки со стороны ISP или же, по крайней мере, сбить его таким образом с толку?

    Да, я размышлял над подобными методами. Одним из вопросов, которых я даже не коснулся в этом выступлении, просто забыл, наверное, является наличие сторонних каналов самых различных видов, в случае с которыми, когда вы создаёте узел здесь, а я подсоединяюсь со своего телефона к собственному узлу, расположенному у меня дома, размер моей транзакции будет отмечен в каком-то случайном SSL-соединении, и это немедленно всплывёт. Таким образом, это может сработать, но также существует вероятность, и это зависит от того, как вы свяжетесь с другим пользователем, с другим узлом, а также, насколько агрессивное наблюдение ведёт ваш ISP. Ведь они видят соединение, другое соединение схожего размера, но, опять же, корреляция не будет простой в этом случае, но она будет. Я так думаю. Я в достаточной мере ответил на ваш вопрос?

    О'Кей, в достаточной.

    [смех]

    [аплодисменты]


    Источник: Dandelion Onions: Protecting Transaction Privacy in Monero

    Перевод:
    Mr. Pickles (@v1docq47)
    Редактирование:
    Agent LvM (@LvMi4)
    Коррекция:
    Kukima (@Kukima)
     
    #1 Mr. Pickles, 3 сен 2019
    Последнее редактирование: 12 сен 2019
    TheFuzzStone нравится это.
  • О нас

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