Всем привет, время еженедельного обновления

  • Index
  1. Состояние сети 2) 0.5 3) i2pmail.v2 4) azneti2p_0.2 5) ???
    1. Net status

Хм, особо сообщать нечего — всё работает так же, как и на прошлой неделе, размер сети примерно тот же, возможно, чуть больше. Появляются новые интересные сайты — подробности смотрите на форуме [1] и у orion [2].

[1] http://forum.i2p.net/viewforum.php?f=16 [2] http://orion.i2p/

    1. 0.5

Благодаря помощи postman, dox, frosk и cervantes (и всем, кто пропускал данные через свои routers ;), мы собрали статистику по размерам сообщений за целые сутки [3]. Там представлены два набора статистики — высота и ширина зума. Это было продиктовано желанием изучить влияние различных стратегий padding (добавочного заполнения) сообщений на нагрузку сети, как объясняется [4] в одном из черновиков по маршрутизации tunnel версии 0.5. (ooOOoo красивые картинки)

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

[3] http://dev.i2p.net/~jrandom/messageSizes/ [4] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/ tunnel.html?rev=HEAD#tunnel.padding

Собственно, та ссылка [4] приводит нас к текущему состоянию планов версии 0.5 по маршрутизации tunnel. Как писал Connelly [5], в последнее время в IRC было много обсуждений некоторых черновиков, где polecat, bla, duck, nickster, detonate и другие предлагали идеи и задавали наводящие вопросы (ладно, и ехидные комментарии ;). Спустя чуть больше недели мы наткнулись на потенциальную уязвимость, описанную в [4], связанную со сценариями, когда противник каким‑то образом захватывает входной шлюз данного tunnel и одновременно контролирует одного из других узлов далее в этом tunnel. Хотя в большинстве случаев само по себе это не раскроет конечную точку и по мере роста сети провернуть такое становится маловероятно, всё равно это отстой (tm).

И тут на помощь приходит [6]. Это устраняет ту проблему, позволяет нам использовать tunnels любой длины и решает проблему голода в мире [7]. Однако это открывает другую проблему: атакующий может создавать циклы в tunnel, но, основываясь на предложении [8], которое Taral сделал в прошлом году относительно сеансовых тегов, используемых в ElGamal/AES, мы можем свести ущерб к минимуму, используя серию синхронизированных генераторов псевдослучайных чисел [9].

[5] http://dev.i2p.net/pipermail/i2p/2005-January/000557.html [6] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/ tunnel-alt.html?rev=HEAD [7] Угадайте, какое утверждение является ложным? [8] http://www.i2p.net/todo#sessionTag [9] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/ tunnel-alt.html?rev=HEAD#tunnel.prng

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

В любом случае, как я упоминал в рассылке [10], далее я бы хотел реализовать вторую стратегию [6], чтобы проработать оставшиеся детали. План для 0.5 сейчас - собрать все изменения, несовместимые с предыдущими версиями - новую криптографию для tunnel и т. п. - и выпустить это как 0.5.0, затем, когда это устоится в сети, перейти к другим частям 0.5 [11], таким как корректировка стратегии формирования пулов, как описано в предложениях, и выпустить это как 0.5.1. Я надеюсь, мы всё же успеем выпустить 0.5.0 к концу месяца, но посмотрим.

[10] http://dev.i2p.net/pipermail/i2p/2005-January/000558.html [11] http://www.i2p.net/roadmap#0.5

    1. i2pmail.v2

На днях postman опубликовал черновой план действий для почтовой инфраструктуры следующего поколения [12], и выглядит это чертовски круто. Конечно, мы всегда можем напридумывать ещё больше наворотов, но архитектура во многих отношениях весьма удачная. Ознакомьтесь с тем, что уже задокументировано [13], и свяжитесь с postman, чтобы поделиться своими мыслями!

[12] http://forum.i2p.net/viewtopic.php?t=259 [13] http://www.postman.i2p/mailv2.html

    1. azneti2p_0.2

Как я писал в списке рассылки [14], оригинальный плагин azneti2p для Azureus содержал серьёзную ошибку, затрагивающую анонимность. Проблема заключалась в том, что в смешанных торрентах, где часть пользователей анонимна, а часть — нет, анонимные пользователи подключались к неанонимным пользователям /напрямую/, а не через I2P. Пол Гарднер и остальные разработчики Azureus отреагировали очень оперативно и сразу выпустили патч. Проблема, которую я наблюдал, больше не присутствует в Azureus v. 2203-b12 + azneti2p_0.2.

Мы ещё не провели полный аудит кода на предмет любых потенциальных проблем с анонимностью, так что “используйте на свой страх и риск” (с другой стороны, мы говорим то же самое об I2P до релиза 1.0). Если вы готовы, я знаю, что разработчики Azureus будут признательны за дополнительную обратную связь и отчёты об ошибках по плагину. Мы, разумеется, будем информировать людей, если узнаем о каких-либо других проблемах.

[14] http://dev.i2p.net/pipermail/i2p/2005-January/000553.html

    1. ???

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

=jr