Встреча разработчиков I2P - 18 января 2005 г.

13:04 <jrandom> 0) привет 13:04 <jrandom> 1) Состояние сети 13:04 <jrandom> 2) 0.5 13:04 <jrandom> 3) i2pmail.v2 13:04 <jrandom> 4) azneti2p_0.2 13:04 <jrandom> 5) ??? 13:04 <ant> <duck> (звук крипто-болтовни, пролетающей мимо моих ушей) 13:04 <jrandom> :) 13:04 * jrandom машет 13:04 <cervantes> прив 13:04 <jrandom> вы тоже можете слушать звук крипто-болтовни, пролетающей мимо ваших ушей! еженедельная заметка о статусе опубликована @ http://dev.i2p.net/pipermail/i2p/2005-January/000559.html 13:05 <bla> привет 13:05 <jrandom> перейдём сразу к делу, раз уж мы всё равно прерываем интересное обсуждение... 1) состояние сети 13:05 <jrandom> мне особо нечего добавить к тому, что в письме — у кого‑нибудь есть что‑то, что хочется обсудить насчёт состояния сети? 13:06 <bla> Кроме того, что мы впервые увидели узлы на *всех* континентах, кроме Антарктиды, — нет. 13:06 <jrandom> w00t! 13:07 <jrandom> ок, переходим к 2) делам 0.5 13:07 <mule> эй, мой отец как раз направляется в Антарктиду, надо было выдать ему узел 13:07 <ant> <duck> чёртовы антарктиканцы 13:07 <Xan> ни одного антарктиканца? :( 13:07 <jrandom> хаха, круто 13:07 <jrandom> хотя не думаю, что там большой набор анонимности 13:07 <Frooze> вините Антарктиду 13:08 * cervantes устанавливает нефтяную вышку в Антарктике, чтобы профинансировать там узел 13:09 <jrandom> ладно-ладно, дел по 0.5 много, так что разберём по частям 13:09 <jrandom> для начала спасибо ребятам, собравшим суточную статистику — много интересных данных @ http://dev.i2p.net/~jrandom/messageSizes/ 13:09 <postman> с удовольствием :) 13:10 <cervantes> по поводу состояния сети... в последнее время вижу довольно много людей, у которых проблемы с запуском I2P (на форумах и т. п.) — не знаю, связано ли это просто с ростом числа пользователей или, возможно, появилось больше приложений на базе i2p, в которых может что‑то пойти не так 13:10 <+protokol> jrandom: ЛГУН! ты сказал, что данные интересные! 13:10 * jrandom кидает грязью в protokol 13:11 <ant> <duck> cervantes: я тоже видел сообщения о людях, которые поднимали всё за пару минут 13:11 <ant> <duck> думаю, NAT вызывает большую часть проблем 13:11 <cervantes> duck: верно... 13:11 <ant> <dmdm> кто такой NAT? 13:11 <jrandom> cervantes: проблемы ещё есть, конечно. вопрос с NAT и OS X в последнее время доставал, но помощь Jhor с последним должна улучшить ситуацию 13:12 <cervantes> ага 13:12 <cervantes> *кхм* итак... 0.5 13:13 <Xan> dmdm: преобразование сетевых адресов 13:13 <jrandom> хех, ок. по сути, сбор статистики по размерам сообщений — чтобы исследовать вопросы с дополнением (padding) 13:14 <jrandom> к сожалению, стратегия, которую я накидал, перебирая цифры, вышла отстойной: один padding давал около 25% накладных расходов 13:14 <jrandom> если пойдём по одному из предложений для шифрования в 0.5 (tunnels-alt.html), этой проблемы не будет 13:15 <jrandom> (поскольку он заставит использовать маленькие фиксированные размеры с фрагментацией) 13:15 <mule> какие сообщения вы хотите паддить: те, которые видит router, или те, которые видит внешний наблюдатель? 13:15 <jrandom> mule: важный вопрос 13:15 <jrandom> если нас заботит только внешний наблюдатель, можно оставить сообщения без padding, делая весь chaff на транспортном уровне 13:16 <Teal`c> http://microsoft.i2p/david_hasselhoff_05_christmas_album__silent_night.mp3 13:16 <jrandom> с другой стороны, если нас беспокоит, что участники tunnel делают анализ потоков, нужно заботиться о padding внутри tunnel 13:16 <@duck> при 5-6 переходах насколько велик риск, что router будет заниматься анализом трафика? 13:16 <cervantes> Teal`c: встреча сейчас... можешь использовать #i2p-chat для анонсов mp3 ;-) 13:17 <Teal`c> сорри 13:17 <cervantes> :) ради David Hasselhoff? 13:18 <jrandom> зависит от уровня анализа, duck. если они как‑то вычислили, в каком tunnel находятся (например, они — шлюз входящего tunnel и выкачали netDb, соотнеся его с destination), это нетривиальные данные. с другой стороны, это не прямое раскрытие, но кое‑какую инфу даёт 13:18 <jrandom> ещё важнее, чем padding в tunnel, — сквозной (end‑to‑end) padding, скрывающий данные о потоках сообщений от шлюзов и конечных точек. 13:19 <jrandom> если мы совсем свихнёмся/поглупеем, можем сделать настоящий pipenet, используя постоянный битрейт везде 13:19 <+polecat> Я понял! 13:19 <jrandom> (и в итоге останемся без пользователей i2p) 13:19 <+polecat> Нам нужно туннелировать i2p через email! 13:19 <cervantes> какова вероятность того, что сговорившиеся routers окажутся в одном tunnel на достаточно большой сети? 13:19 <+polecat> Ни один ISP не будет настолько глуп, чтобы блокировать email! 13:20 * jrandom ожидает реализацию net.i2p.router.transport.gmail 13:20 <postman> polecat: боже, какая чушь 13:20 <postman> :) 13:20 <bla> cervantes: N^(-h) (N — # быстрых узлов, h = # переходов). Похоже на то 13:20 <+polecat> =3 знаю. 13:21 <cervantes> это много? :) 13:21 <jrandom> не число быстрых узлов, так как внешние не знают ваши профили 13:21 <+polecat> Если серьёзно, нагло злоупотребляя существующими IP‑сервисами, мы могли бы туннелировать i2p множеством изобретательных способов. 13:21 <jrandom> c^2/N^h, чтобы получить двух пиров в одном tunnel 13:21 <jrandom> согласен, polecat. это одна из причин, почему у нас нет двунаправленных tunnels 13:22 <jrandom> некоторые транспорты (например, email) отвратительны для двунаправленной связи 13:22 <bla> jrandom: c = ? 13:22 <jrandom> c == # сговорившихся пиров 13:23 <+polecat> Хм, интересная мысль. 13:23 <ant> <duck> с точки зрения роадмапа, каков эффект, если i2p пойдёт не в ту сторону и выберет неправильное крипто-решение? 13:23 <+polecat> Или протокол с почтовыми голубями — двунаправленности там ноль. 13:23 <+polecat> крипто уже модульно, не так ли? 13:23 <jrandom> duck: это лишь один подпункт из 0.5 и один подраздел в документе tunnels*.html. маршрутизация через tunnel — это не только то, как мы заворачиваем данные 13:24 <bla> jrandom: но это вероятность попасть в один tunnel *сейчас*. Однако по T обновлениям tunnel (каждые сколько‑то минут) это будет P = 1 - (1 - c^2/N^h)^T 13:24 <jrandom> с другой стороны, разница между "fixed 1KB blocks" и "0-40KB blocks" оказывает существенное влияние 13:24 <+polecat> Не хотел бы, чтобы эта сеть пошла по пути Entropy, застряв на McEliece. 13:24 <jrandom> polecat: прочти http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD 13:24 <bla> jrandom: И таким образом стремится к нулю при достаточно большом времени. То есть при достаточно большом времени атакующие окажутся в одном tunnel хотя бы один раз 13:25 <jrandom> план — стандартный AES256/CBC 13:25 <+protokol> я слышал, что через DNS хорошо туннелировать штуки — большинство его не блокирует 13:25 <jrandom> конечно, bla, хотя не всё так прямолинейно (для exploratory tunnels — да, но не для client tunnels) 13:26 <+polecat> И если вдруг даже AES сломают — какой‑нибудь эквивалентный симметричный шифр. 13:27 <jrandom> bla: не думаю, что это настолько большая практическая проблема в большинстве случаев, но когда ты монтируешь её как часть атаки предшественника, вопрос уже почти теряет смысл 13:28 <jrandom> (из‑за того, как мы делаем остальную маршрутизацию через tunnel) 13:28 <bla> jrandom: ок 13:28 <jrandom> верно, polecat 13:29 <jrandom> duck: если выберем второй вариант, сменить его позже вероятно будет легко. 13:29 <jrandom> с другой стороны, второй вариант потребует серьёзной оптимизации производительности, чтобы Не Было Отстоя 13:29 <jrandom> но уверен, мы справимся 13:31 <jrandom> в общем, думаю, выше описано, где мы сейчас находимся с работами по 0.5 13:31 <jrandom> у кого‑нибудь есть ещё вопросы/комментарии/опасения? 13:31 <bla> jrandom: Один 13:32 <bla> jrandom: думаю, нам стоит ценить анонимность чуть больше, чем производительность прямо сейчас: так что да, вариант с PRNG звучит хорошо 13:33 <jrandom> согласен. производительность можно подтянуть позже, а вот "добавить" лучшую анонимность гораздо сложнее 13:33 <jrandom> (но, конечно, производительность — это /тоже/ параметр безопасности. если оно Отстой, никто не будет пользоваться) 13:33 <bla> Да. 13:33 <bla> jrandom: 13:33 <bla> сорри 13:33 <@duck> верно, /me щёлкает магический флажок производительности Freenet 13:33 <cervantes> возможно, это отпугнёт всех любителей размахивать торрентами ещё на какое‑то время ;-) 13:34 <jrandom> хех 13:34 <cervantes> <-- connection reset 13:34 <bla> cervantes: Нет, я не такой! :) 13:34 <cervantes> :) 13:35 <jrandom> думаю, мы сможем провернуть классные оптимизации, и похоже, что многое упирается не в выбор пиров, а просто (хех) в баги в jobqueue 13:36 <jrandom> но, в любом случае, что‑нибудь ещё по 2) 0.5? 13:36 <ant> <BS314159> не мог бы ты выложить объяснение этой атаки с петлёй (loop attack)? 13:37 <ant> <BS314159> звучит опаснее, чем следует из твоего описания 13:37 <jrandom> loop: построить tunnel, содержащий A-->B-->C-->D-->C, и послать внутрь 10 сообщений. 13:37 <jrandom> без PRNG (ГПСЧ) можно добавлять сколько угодно сообщений в эту петлю C<-->D 13:38 <ant> <BS314159> ок 13:38 <jrandom> фактически устраивая DoS любым routers всего несколькими сообщениями 13:38 <ant> <BS314159> но только A может это сделать 13:38 <jrandom> с PRNG это ограничит количество сообщений, которые могут войти в петлю 13:38 <ant> <BS314159> то есть нет опасности, что атакующий укоротит мои tunnels, добавив петли 13:38 <jrandom> нет, никто не может укоротить твои tunnels 13:39 <jrandom> единственное, для чего это полезно — DoS 13:39 <jrandom> (очень дешёвый DoS) 13:39 <jrandom> (но когда можно избирательно DoS'ить пиров без больших затрат, можно творить ооочень неприятные вещи) 13:40 <ant> <BS314159> компрендо 13:40 <+protokol> и hashcash‑серты помогут с этим? 13:40 <jrandom> protokol: hashcash решает проблему с тем, что пир строит слишком много tunnels, и, возможно, слишком много переходов 13:41 <jrandom> protokol: с петлями это не помогает. два способа, которые я нашёл и которые /помогают/, — это PRNG (tunnel-alt.html) или проверка на каждом шаге (tunnel.html) 13:42 <jrandom> у проверки на каждом шаге есть опасности, поэтому сейчас склоняемся к PRNG 13:42 <+Ragnarok> насколько эффективен будет метод с PRNG? 13:42 <Xan> A-->B-->C-->D-->C — разве каждый hop не должен получать другой id или что‑то такое, чтобы сообщения выходили из tunnel при втором попадании в C, а не зацикливались? 13:43 <jrandom> Xan: получают, но без проверки на каждом шаге нельзя понять, плохо это или нет 13:44 <jrandom> Ragnarok: думаю, очень эффективно минимизирует наносимый ущерб 13:45 <jrandom> по крайней мере, насколько я вижу сейчас 13:45 <jrandom> если кто видит какие‑то проблемы/вопросы с этим или предложения по улучшению, пожалуйста, дайте знать :) 13:46 <Xan> или, может, я не улавливаю мысль 13:46 <Xan> вернусь позже 13:46 <jrandom> ок, позже, я обновлю док, чтобы было понятнее 13:47 <jrandom> ок, если больше ничего нет, перейдём к 3) i2pmail.v2? 13:47 <jrandom> postman: ты здесь? 13:48 <postman> да 13:49 <postman> :) 13:49 <jrandom> есть что добавить к твоему посту на форуме? звучит довольно круто 13:49 <postman> ну, некоторые из вас, возможно, уже читали черновик i2pmail.v2 13:50 <bla> что за фигня происходит? Массовые дисконнекты. У меня тоже проблемы с доступом к сайтам (скажем, orion, library) 13:50 <postman> она нацелена на полностью децентрализованную почтовую инфраструктуру в будущем 13:50 <postman> но потребуются proxy‑софт на узлах, а также несколько выделенных ретрансляторов 13:51 <postman> все приглашаются вносить идеи / концепции / ругань 13:51 <postman> разработка уже началась — не ждите ничего раньше конца весны :) 13:51 <jrandom> w00t 13:51 <kaji> хмм, у меня только что у двери появились копы 13:52 <bla> kaji: ? 13:52 <jrandom> быстро, взорви жёсткий диск 13:52 <postman> jrandom: ну, это всё, что я хотел сказать сейчас :) 13:52 <cervantes> спрячьте стол для блэкджека! 13:52 <jrandom> круто, спасибо, postman 13:52 <kaji> сказали, что я набрал 911, но я уверен, что ни я, ни брат этого не делали 13:53 <+protokol> kaji: они просто проверяют i2p 13:53 <jrandom> ок, если больше ничего по 3) i2pmail, перейдём к 4) azneti2p_0.2 13:53 <+protokol> <creepy music> 13:53 <jrandom> как упоминалось в письме, в последнее время был важный прогресс 13:53 <kaji> потом сказали, что беспроводные телефоны могут чудить, когда снята трубка, но все мои беспроводные на зарядке -> #i2p-chat 13:55 <jrandom> ребята из Azureus очень оперативно готовят обновление (ура!), но людям также стоит быть начеку насчёт проблем 13:55 <jrandom> (если вы не читаете список рассылки i2p и используете azneti2p, читайте список рассылки i2p) 13:55 <jrandom> ((или даже если вы не используете azneti2p, читайте рассылку — там мы объявляем важные вещи ;) 13:56 <jrandom> duck и orion тоже сделали кучу обновлений, чтобы подстроиться под новый bt‑клиент и форматирование 13:56 <jrandom> (ура!) 13:56 * orion улыбается 13:57 <orion> ещё есть над чем работать, но пока что это работает. 13:57 <jrandom> (насколько i2p это позволяет ;) 13:58 <orion> хехе, да. ;) 13:58 <jrandom> у кого‑нибудь ещё есть что обсудить по поводу azneti2p или i2p-bt? 13:58 <jrandom> (или bytemonsoon2p ;) 14:00 <jrandom> ок, если нет, двигаемся дальше к 5) ??? 14:00 <jrandom> свободная дискуссия — ещё что‑нибудь? 14:00 <postman> jrandom: почему addressbook публикует записи из userhosts? 14:01 <jrandom> postman: баг. 14:01 <postman> то есть это не планировалось и будет изменено? 14:01 <cervantes> только одно... 14:01 <jrandom> postman: верно, и будет изменено 14:02 <jrandom> (верно, Ragnarok? :) 14:02 <+Ragnarok> зависит от того, что именно имеет в виду postman... 14:03 <jrandom> Ragnarok: новые записи, добавленные локальным пользователем в его private hosts, не должны попадать в публикуемые hosts 14:03 <jrandom> (например, userhosts.txt — приватный, hosts.txt синхронизируется с другими и является публичным) 14:03 <cervantes> В рамках полурегулярной рубрики на форуме будет признание и награды тем, кто внёс хорошие вещи в I2P — недавно или за всю историю проекта 14:03 <postman> Ragnarok: после обновления до 0.4.2.6 я обнаружил записи из моего userhosts.txt в опубликованной addressbook в папке моего eepsite 14:03 <ant> <BS314159> хмм 14:04 <postman> Ragnarok: это были вручную добавленные ключи, которые не предполагалось публиковать 14:04 <cervantes> на этой неделе мы отмечаем duck за общую крутость как провайдера сервисов для сообщества и как вообще отличного айдлера: http://forum.i2p/viewtopic.php?t=275 14:04 <jrandom> w00t! 14:04 <jrandom> (вперёд, duck, вперёд) 14:05 <Teal`c> а как насчёт захвата доменных имён? 14:05 * brachtus аплодирует 14:05 * orion делает «утиную походку» в знак уважения. 14:05 <cervantes> важный момент на будущее... не обязательно быть криптографическим гением, чтобы получить похвалу! 14:06 <+Ragnarok> нет, это ожидаемое поведение. Я могу это изменить, но сначала мне нужно закончить реализацию блокировки файлов, чтобы вы могли изменять hosts.txt напрямую 14:06 <orion> (но это помогает) 14:06 <cervantes> вы могли просто сделать классный eepsite или что‑то такое... 14:06 <cervantes> или быть полезным парнем на форуме и т. п. 14:07 <ant> <BS314159> хмм 14:07 <cervantes> (иначе, давайте честно, jrandom побеждал бы каждую неделю) 14:07 <jrandom> эй, вы же пополняете мой пивной фонд, это же не бесплатно ;) 14:07 <ant> <BS314159> не могли бы вы просто сделать новый файл, "publichosts.txt"? 14:07 <ant> <BS314159> затем заставить addressbook игнорировать userhosts.txt, но позволить пользователям подписываться на свой publichosts.txt? 14:08 <jrandom> Teal`c: никак нельзя угнать доменное имя: никакие записи не перезаписываются, и userhosts всегда имеет приоритет над hosts 14:09 <jrandom> Ragnarok: возможно, веб‑интерфейс может решить вопрос блокировок, ведь пользователи не будут добавлять в файлы вручную 14:09 <+Ragnarok> когда блокировка будет готова, не будет реальной причины подтягивать адреса из userhosts.txt (сейчас это единственный способ избежать гонки), так что особого смысла добавлять третий файл нет 14:10 <+Ragnarok> jrandom: ну, я планировал использовать Java API блокировки файлов 14:10 <jrandom> если считаешь это необходимым, ты босс :) 14:10 <ant> <BS314159> это позволило бы убрать все имена, полученные от других, сохранив те, что вы добавили сами 14:10 <ant> <BS314159> просто очистив hosts.txt и изменив свою подписку 14:11 <ant> <BS314159> но думаю, это может подождать подписи имён 14:11 <orion> метаданные решат эту проблему. Черновик спецификации уже есть? 14:11 <jrandom> двух файлов должно быть достаточно — один управляется addressbook, другой нет 14:12 <jrandom> (можно даже заставить addressbook полностью игнорировать userhosts.txt — userhosts.txt всё равно перекрывает hosts.txt) 14:12 <+Ragnarok> jrandom: таков план, как только будет готова блокировка (что на самом деле не должно быть слишком сложно, я просто пока не добрался :) 14:13 <+Ragnarok> и сейчас я изучаю достаточно XML Schema, чтобы написать схему для namerecords 14:13 <ant> <dr_kavra> это канал для kenosis? другой канал сказал прийти сюда :D 14:13 <jrandom> лол 14:13 <jrandom> неа, извини, это i2p 14:14 <jrandom> (если только ты не ищешь анонимный коммуникационный слой) 14:14 <jrandom> круто, Ragnarok 14:14 <ant> <BS314159> я всё же считаю, что XML слишком многословен и нечитаем для такого по сравнению с YAML, но код пишу не я 14:14 <jrandom> Ragnarok: сложно будет сделать крипто с XML, не скатившись к уродливому CDATA 14:14 <orion> кто‑нибудь уже написал рабочий черновик спецификации метаданных? 14:15 <jrandom> (лично я думаю, что xml отстой, но я просто критикан) 14:15 <jrandom> orion: http://dev.i2p.net/pipermail/i2p/2004-February/000135.html имеет базовую схему 14:15 <orion> (метаданные имени/ключа) 14:15 <dox> адресная книга и её функции где‑то анонсировались? я не знал, что мой hosts.txt публикуется 14:15 <jrandom> (см. элементы NameReference и LocalEntry) 14:16 <jrandom> dox: он пишется в путь, указанный в addressbook/config.txt 14:16 <jrandom> (по умолчанию, ./eepsite/docroot/hosts.txt) 14:17 <orion> не хватает флага public/private (т. е. распространять/нет). 14:17 <ant> <cervantes> единственное хорошее в XML (и это большой плюс) — он широко принятый стандарт 14:17 <jrandom> верно, orion, с тех пор появилось много хороших идей 14:17 <+Ragnarok> xml может и отстой, но, честно говоря, для моей задачи он лучше альтернатив 14:17 <jrandom> cervantes: как и EDI 14:17 <orion> есть место, где их собрать? например, раздел форума? 14:18 <orion> или, может, страница в вики? 14:18 <jrandom> orion: вики susi или ugha 14:18 <orion> Я собираюсь поднять вики для bytemonsoon и orion.i2p, чтобы сообществу было легче прийти к консенсусу по будущим целям разработки каждого. 14:18 <BrockSamson> xml + crypto без CDATA = MIME, не? 14:19 <jrandom> круто, orion 14:19 <jrandom> BrockSamson: S/MIME, с другими парсерами ;) 14:19 <orion> (а также одну для метаданных имён) 14:21 <jrandom> метаданные можно сделать множеством способов; важно — гибкость и «корректность», чтобы оно могло расти и меняться со временем 14:21 * jrandom уверен, Ragnarok и др. придумают что‑нибудь хорошее :) 14:21 <orion> поэтому я думаю, нужен публичный черновик. 14:22 <ant> <cervantes> консорциум i2p :P 14:22 <jrandom> ну, люди уже несколько встреч подряд говорят "кто‑нибудь должен выложить свои идеи на вики", но страницы вики не особо растут ;) что нормально, идём в своём темпе 14:23 * orion обещает за день поднять три вики и разослать всем их адреса по email 14:23 <BrockSamson> назовите меня ленивым, но сравните ANSI 850 Purchase Order EDI почти с любым XML‑based Purchase Order — я лучше буду декодировать, кодить и отлаживать версию на XML. Даже если она в 5 раз больше EDI 14:23 <jrandom> w00t 14:23 <jrandom> хех, BrockSamson 14:24 <BrockSamson> Позиция 10 — ST? тогда позиция 310 должна быть имя 14:24 <BrockSamson> эх, я 14:24 <jrandom> BrockSamson: не думаю, что XML‑схемы для PO намного лучше ;) 14:24 <jrandom> (но да, это всё полный ужас) 14:25 <BrockSamson> в 4:30 утра — лучше 14:25 <BrockSamson> если только... 14:25 <jrandom> хех 14:25 <BrockSamson> это не написано бывшим EDI‑программистом 14:25 <BrockSamson> и xml выглядит так: <p1><po><q>1</q></po></p1> 14:26 <BrockSamson> спорю, что если сложить часы, которые проекты с открытым исходным кодом тратят на разговоры «быть XML или не быть XML», можно было бы написать Linux раз в десять. 14:26 <BrockSamson> в каждом проекте, где я был, по этому поводу были огромные дебаты 14:27 <orion> дебаты полезны для проекта, смотря кто спорит ;) 14:27 <jrandom> ну, оно делает своё дело, но это не панацея. может хорошо подойти для именования 14:28 <BrockSamson> многие в проектах только для того, чтобы спорить. 14:28 <jrandom> не здесь. я здесь ради бесплатного пива 14:28 <ant> <cervantes> это спорно 14:28 <orion> детали реализации прояснятся, когда черновик спеки станет более осязаемым. 14:28 <orion> отсюда и необходимость в вики/пир‑ревью. 14:29 <BrockSamson> я слышал, что в этом проекте раздают бесплатный чеснок 14:29 <jrandom> много 14:30 <jrandom> ок, есть ещё что поднять на встрече? 14:30 <ant> * cervantes выкатывает церемониальную корову с колокольчиком 14:30 <ant> <cervantes> call =cow 14:30 * jrandom размахивается 14:31 * jrandom *baf* бьёт в коровий колокол, закрывая встречу