Встреча разработчиков I2P - 07 февраля 2006

15:36 <jrandom> 0) привет 15:36 <jrandom> 1) Состояние сети 15:36 <jrandom> 2) Прогресс _PRE net 15:36 <jrandom> 3) I2Phex 0.1.1.37 15:36 <jrandom> 4) ??? 15:36 <jrandom> 0) привет 15:37 * jrandom машет 15:37 <jrandom> еженедельные заметки о статусе опубликованы @ http://dev.i2p.net/pipermail/i2p/2006-February/001258.html 15:37 <bar> привет 15:38 <jrandom> пока вы все копаетесь в этом о-о-очень захватывающем материале, давайте перейдем к 1) Состояние сети 15:38 <jrandom> за последнюю неделю в живой сети мало что изменилось, с точки зрения i2p, так что мне особо нечего добавить 15:39 <jrandom> у кого-нибудь есть что-то, что хотите поднять касательно текущего состояния сети? 15:39 <KBlup> Я видел ужасные всплески сбоев клиентов при долгой работе i2p... не знаю, относится ли это к 1) 15:39 <jrandom> KBlup: это коррелирует с высокой загрузкой CPU или потреблением полосы? 15:40 <KBlup> в результате msg-delay> 10000ms :-/ 15:40 <jrandom> ах, очень вероятно одна из причин, по которой разрабатывается _PRE net :) 15:40 <KBlup> Думаю, он тогда пытается устанавливать новые tunnel (туннель) и постоянно падает, что иногда приводит к 300+ jobs... 15:41 <KBlup> моя машина довольно мощная, но с этим перегружается... 15:41 <jrandom> ага, все это переработано в ходе работы над 0.6.1.10, подождите, пока это будет готово 15:43 <jrandom> ладно, еще что-нибудь по 1), или двинемся к 2) Прогресс _PRE net 15:43 <+Complication> похоже, 0.6.1.10 действительно содержит существенные изменения 15:45 <jrandom> да, тут много «мяса». Текущее состояние: новый код создания на месте и, кажется, работает правильно, но сейчас я пользуюсь случаем, чтобы глубже отладить некоторые лежащие в основе проблемы 15:46 <+Complication> Вы упоминали, что приходится заранее выделять много CPU‑времени 15:47 <+Complication> Эта цена теперь будет связана с созданием любого вида tunnel? 15:48 <+Complication> (то есть перед созданием, в течение короткого времени, придется выполнить пакет тяжелых криптоопераций) 15:48 <jrandom> да, все запросы на построение tunnel должны будут выполнить k тяжелых криптоопераций (где k = число переходов в создаваемом tunnel) 15:49 <+Complication> Что я хотел спросить... интервал просто более сжатый, чем раньше, или объем тоже больше? 15:50 <jrandom> и больше, и меньше, и плотнее. плотнее — в том смысле, что всё делается заранее. больше — потому что мы не можем схитрить и не выполнять шифрование для перехода, если более ранний переход его отвергает, и меньше — потому что ранние переходы падают гораздо реже 15:51 <jrandom> кроме того, в отличие от прежних релизов, мы больше не используем ElGamal/AES+SessionTag для запросов на tunnel — мы используем (в целом) прямой ElGamal 15:52 <+Complication> …и это нельзя было бы предвычислить, если только не известен конечный набор, который пройдет? 15:52 <jrandom> это означает, что раньше мы могли хитрить без асимметричной операции, но теперь больше не пытаемся хитрить (так как сама хитрость раскрывала класс атак) 15:53 <+Complication> (набор пиров) 15:53 <jrandom> хмм, это вполне можно предвычислить, если вы знаете, какие пиры в tunnel будут опрошены 15:54 <jrandom> новый процесс создания tunnel выполняется в отдельном потоке, чтобы под нагрузкой не забивать основную очередь jobs и чтобы он мог лучше сам себя дросселировать 15:54 <+Complication> Можно ли также предположить, что при неизменности доступных знаний известны несколько тех, к кому будешь обращаться при неудачах попыток? 15:54 <jrandom> хмм, не совсем понял 15:55 <+Complication> Или знание их бесполезно, поскольку структуру нужно переделывать с нуля? 15:56 <+Complication> (то есть, по крайней мере, ElGamal приходится делать заново) 15:56 <jrandom> ах, структура — http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.requestRecord 15:56 <jrandom> так что да, если меняется следующий переход, ElGamal нужно делать заново 15:56 <jrandom> (если вы предвычисляете) 15:56 <+Complication> Верно, я не был в этом сразу достаточно уверен 15:57 <+Complication> Теперь понимаю 15:57 <jrandom> с другой стороны, мы действительно стараемся повысить долю успешных сборок, и новый процесс построения должен уметь адаптироваться, чтобы минимизировать ненужные создания 15:58 <+Complication> Как это выглядит на практике? 15:58 <jrandom> (о, эта структура была немного изменена в ветке _PRE: http://dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/router/doc/tunnel-alt-creation.html?rev=1.1.2.1;content-type=text%2Fhtml#tunnelCreate.requestRecord ) 15:59 <+Complication> Я заметил подробность о том, что шифрования ElGamal резко ускорились... 15:59 <jrandom> ну, доля успешных сборок намного выше, чем в живой сети, но это может быть лишь из‑за маленького размера _PRE net 16:00 <jrandom> да, например, создание структуры из 2 переходов занимает в среднем 44 мс по 1120 прогонам, по сравнению со временем шифрования ElGamal в живой сети в 542 мс (по 1344 прогонам) 16:02 <jrandom> (на той же машине) 16:02 <+Complication> Эти 542 включают повторы при сбоях, или это чистое построение? 16:02 <+Complication> Если это чистое построение, мне нужно найти свою нижнюю челюсть... она где-то на полу. :P 16:02 <KBlup> насчет изменения экспоненты: в каком масштабе это влияет на анонимность? 16:02 <jrandom> нет, это чистая статистика ElGamal, поскольку живая сеть не строит новую структуру _PRE net 16:04 <jrandom> KBlup: анонимность? никак. безопасность? судя по тому, что я читал, 228 бит более чем достаточно, чтобы соответствовать 2048‑битному ElGamal 16:04 * Complication мало знает о x и y в ElGamal 16:04 <+Complication> Недостаточно, чтобы содержательно комментировать 16:06 <+Complication> Если серьезные исследователи считают укороченный x достаточно сложным, и эти крипто‑гуру не убежали с криками... 16:06 <@cervantes> ну не только это, но и последствия перехода на 1024/160 16:07 <KBlup> полагаю, мне придется позже прочитать статью ;) 16:07 <+Complication> cervantes: да, это точно лучше, чем то 16:08 <+Complication> Кроме того, какая главная атака, от которой этот шифр должен защищать, и как долго такая атака жизнеспособна? 16:09 <+Complication> Это что-то, что приносит пользу только если взломать быстро, или приносит пользу и при взломе когда-нибудь потом? 16:11 <+Complication> Если я правильно понимаю, ближайший секрет, который он защищает, — это следующий участник tunnel, верно? 16:11 <+Complication> (точнее, следующий после следующего) 16:11 <@modulus> встреча идет? 16:11 <+Complication> (о котором знает только следующий) 16:11 <@cervantes> modulus: ayre 16:11 <@cervantes> -r 16:11 <jrandom> для практического (пусть и безумно мощного) противника необходимо взломать его в течение времени жизни tunnel. взлом после времени жизни tunnel поможет только если вы логировали весь сетевой трафик и взломали все tunnel (то есть, после взлома эфемерной криптографии транспортного уровня и работы над криптографией уровня tunnel) 16:11 <jrandom> так что речь идет о минутах, а не десятилетиях 16:12 <jrandom> (так что 1024‑бит, вероятно, даже избыточно) 16:12 <@cervantes> есть ли способ осмысленно измерить риск? 16:13 <+Complication> Кроме того, для tunnel с большим числом переходов противнику пришлось бы взломать несколько, верно? 16:13 <+Complication> (хотя строителю тоже пришлось бы строить несколько) 16:13 <@cervantes> если нам нужно не больше 1024 бит, действительно ли необходимо использовать больше? 16:14 <@cervantes> мы всегда сможем использовать более сильный алгоритм через 3 года, когда у нас будут куда более мощные квантовые компьютеры 16:14 <@modulus> jrandom: если противник знает, что в момент hh:mm что-то важное пойдет через tunnel, вероятно ли, что он сможет взломать это как-то с помощью логирования? 16:14 <jrandom> Complication: верно, им пришлось бы взломать несколько (и DH‑ключи, защищающие транспортный уровень) 16:14 <@modulus> насколько мне известно, 1024‑бит is break()able при больших мощностях 16:15 <jrandom> большие мощности и десяток лет 16:15 <jrandom> (или три) 16:15 <@cervantes> jrandom: сложно попробовать более слабый шифр? 16:15 <@modulus> у меня было впечатление, что нынче 1024‑битные составные факторизуются за несколько месяцев. 16:15 <@cervantes> мы могли бы выкатить это на pre net 16:15 <@cervantes> и посмотреть, дает ли это действительно большую выгоду 16:16 <@cervantes> modulus: да, но им пришлось бы взломать несколько 16:16 <@modulus> если это основано на дискретном логарифме и всем этом, то я ничего не знаю 16:16 <@modulus> cervantes: ага 16:16 <jrandom> cervantes: это требует изменений во многих структурах, поскольку сейчас мы используем 512‑байтные слоты. хотя, возможно, для теста мы могли бы просто заполнить первые 256 байт 0x00 16:17 <jrandom> modulus: ElGamal основан на дискретном логарифме 16:17 <@cervantes> jrandom: стоит протестировать? 16:17 <@modulus> да-да, я думал про RSA 16:17 <@cervantes> или лучше сосредоточиться на другом и вернуться к этому при необходимости 16:18 <jrandom> определенно стоит потестить, хотя сейчас я ковыряюсь в некоторых оценках транспортного уровня 16:18 <+Complication> Полагаю, это зависит от того, как их вычисление будет в реальности обрабатываться. 16:18 <jrandom> (и время шифрования 44 мс пока достаточно, хотя 4 мс было бы еще лучше :) 16:19 <+Complication> Если это держится на текущих компьютерах, с новыми машинами станет лучше. 16:19 <@modulus> особенно если появится крипто‑железо, как уже начинает появляться кое‑где 16:19 <jrandom> но, конечно, менять этот параметр не будут легкомысленно или сразу. но если у кого-то есть веская причина избегать этого, пожалуйста, свяжитесь 16:21 <jrandom> modulus: я слышал о специализированных чипах AES и RSA, но не о DH/ElGamal. с другой стороны, если смотреть на NSA/и т. п. как на противника, где они могут сделать свои, это возможно 16:22 <@cervantes> у них криптомашины, построенные на технологии кольцевых пончиков с посыпкой 16:23 * Complication готов апгрейдить Celeron 300 до Athlon 600, если это удержит натиск пончиков с посыпкой в виде колец :D 16:23 <tethra> хехех 16:24 <jrandom> ммММмм пончики 16:25 <jrandom> ок, есть ли еще что-нибудь по 2) Прогресс _PRE net? 16:25 <jrandom> если нет, давайте перейдем к 3) I2Phex 0.1.1.37 16:26 <jrandom> Complication: хочешь вкратце рассказать? 16:26 <+Complication> Ну, похоже, оно работает. :) 16:26 <+Complication> Есть надежда скоро получить больше webcache'ов для дополнительной отказоустойчивости. 16:27 <jrandom> ок 16:27 <jrandom> хмм, думаешь, нам нужно больше webcache'ов? разве нам не нужен просто один, чтобы был в онлайне? не то чтобы больше помешало, конечно 16:27 <+Complication> (если legion сумеет решить загадки, которые преследовали его первую попытку) 16:27 <+Complication> Там также есть загадочный баг, но он не кусается сильно, и я пытаюсь его найти. 16:28 <+Complication> Достаточно одного рабочего 16:28 <+Complication> Большее число просто повышает шансы, что хотя бы один в онлайне 16:28 <jrandom> круто 16:28 <+Complication> Потому что на текущем этапе он никогда не будет помечать webcache'ы как плохие. Их вообще слишком мало. 16:29 <+Complication> (та процедура активируется, если существует больше 10) 16:29 <+Complication> (если я правильно помню) 16:29 <+Complication> Что касается бага: после длительной работы подсистема webcache иногда замирает 16:30 <+Complication> Вероятно, потому что GET‑запрос httpclient не удается корректно прервать 16:31 <@modulus> то есть ему нужно умирать время от времени? 16:31 <+Complication> Это безопасно и, похоже, никогда не кусает свежеподключившиеся машины 16:31 <jrandom> хмм, что это значит функционально? через некоторое время он перестанет регистрироваться в webcache, так что новым людям не будут выдаваться на них ссылки? 16:31 <+Complication> Если это кусает уже хорошо интегрированную машину, она сможет получить достаточно пиров от тех пиров, к которым уже подключена 16:31 <+Complication> Так что сейчас влияние кажется близким к нулю 16:31 <@modulus> круто 16:32 <+Complication> Это просто любопытно 16:32 <@modulus> нет какого-то правила, когда это сломается, или чего-то такого? 16:32 <+Complication> modulus: как правило, не раньше чем через 20 часов 16:33 <+Complication> И поскольку у меня нет способа заставить это возникнуть, отладка идет медленно 16:33 <@modulus> :_) 16:34 <+Complication> В любом случае: найду — исправлю, не найду — найду другое, с чем повозиться :) 16:34 <jrandom> :) 16:34 <jrandom> похоже, это просто симптом некоторых багов, которые мы видели в streaming lib / eepproxy, так что исправление их должно исправить и это 16:35 <+Complication> Может быть 16:38 <jrandom> ок, отлично, хорошая работа, Complication 16:38 <jrandom> у кого-нибудь есть что-то еще по 3) I2Phex 0.1.1.37, или перейдем к «всё остальное», 4) ??? 16:41 <jrandom> (считайте, что перешли) 16:41 <jrandom> ок, есть ли еще что-нибудь для встречи? 16:42 <tmp> Или сдерживайте дыхание вечно? 16:43 <jrandom> и вечно, и вечно 16:43 * jrandom готовится 16:43 * jrandom *baf* закрывает встречу